Importing the fusefs kernel module?

Garrett Cooper gcooper at FreeBSD.org
Wed Oct 27 00:46:58 UTC 2010


On Tue, Oct 26, 2010 at 4:20 PM, Scott Long <scottl at samsco.org> wrote:
> On Oct 26, 2010, at 2:58 PM, David Schultz wrote:
>> On Tue, Oct 26, 2010, Kostik Belousov wrote:
>>> On Mon, Oct 25, 2010 at 10:53:08PM +0200, Ivan Voras wrote:
>>>> Fusefs is the Linux-developed userland filesystem interface which is
>>>> fairly popular in the wild, especially with the "sshfs" module which
>>>> allows mounting of generic ssh/sftp directories in a very easy way.
>>>>
>>>> It was developed in one of the very early Google Summer of Code projects
>>>> (2005) and is now in a bit unusual situation:
>>>>
>>>> 1) it *is* popular, as reports about its breakage arrive pretty soon
>>>> after it breaks
>>>>
>>>> 2) it is currently practically unmaintained. The source code archive is
>>>> from 2008 and the port contains a dozen patches to be applied to it to
>>>> make it work on recent systems
>>>>
>>>> 3) it is also not exactly rock stable, though this has improved with the
>>>> above patches; personally I'd judge it to be as stable as ZFS was two
>>>> years ago so there :)
>>>>
>>>> I'm proposing to import the kernel module into the official tree (there
>>>> are also userland libraries under the GPL; they will stay as ports).
>>>> There are no license conflicts for the kernel module. I see two benefits
>>>> from it:
>>>>
>>>> 1) it will finally integrate the patches needed for it to work in one
>>>> tree and provide the "one official place" to work on it
>>>>
>>>> 2) it will be easier to maintain it here, and changes to the VFS APIs
>>>> would be applied to it in sweeping commits together with other file systems.
>>>>
>>>> I'm not knowledgeable enough to actively work on it (yet) but I can
>>>> mechanically maintain it and generally take care of it.
>>>>
>>>> Objections?
>>> This is not going to work. The code is unmaintained. Committing it into
>>> the src/ just makes the pile of not working code in src/ bigger.
>>
>> I used it about a year ago to grade student projects for a class.
>> I had a bunch of buggy student code interfacing with the kernel
>> module via libfuse, and it was quite stable for my purposes.
>> The project didn't involve supporting mmap, though.
>>
>> When I subsequently upgraded my kernel, however, the port broke.
>>
>> The value of having FUSE in the tree is that it encourages people
>> to put forth the modicum of effort required to ensure that it still
>> compiles when kernel APIs change.  I can't comment on whether it is
>> popular enough to support to such a minimal extent, but it is a
>> nifty little package: you maintain one kernel module, and you get
>> passable support for several dozen filesystems for free.
>
> What is comes down to is that it needs a committed owner, someone who not only will shepherd it into the tree, but also work on continuous improvements and handle bug reports.  I personally think that it would be a good thing to have in the kernel, but I can't afford the commitment.

    If this module was in the tree, could we drop other less
maintained filesystems, like our in-tree ntfs support (/sys/fs/ntfs/)?
I know it sounds radical, but it would be nice to have a working
filesystem instead of a filesystem that's out-of-date and broken like
our in-tree ntfs.
    Also, what about our hfs / hfs+ support? I haven't checked lately
(and I'll confirm when I get home), but it looks like support might be
a bit shaky ( https://forums.freebsd.org/showthread.php?t=1198 ). I
wouldn't mind having good filesystem support for my PowerPC Mac and
iPod :).
    There are some other handy filesystems like sshfs, etc that people
have rolled for other purposes that would be interesting to have
access to.
    So I would be game to help maintain things, but I'd need help
getting up to speed on FUSE and figure out the lay of the land. I
wouldn't be very effective for a while though because I'm not
knowledgeable in the ways of the vfs[, yet?]..
Thanks,
-Garrett


More information about the freebsd-arch mailing list