Userspace filesystems (WAS: Encrypted Filesystem)

From: Miklos Szeredi (Miklos.Szeredi_at_eth.ericsson.se)
Date: 01/28/04

  • Next message: Voicu Liviu: "Re: Official NVIDIA drivers for 2.6" 
    Date:	Wed, 28 Jan 2004 14:50:02 +0100 (MET)
To: azz@us-lot.org

    Adam Sampson <azz@us-lot.org> wrote:

    > Is there a technical reason that none of the userspace filesystem
    > layers have been included in the stock kernel, or is it just that
    > nobody's submitted any of them for inclusion yet?

    I'm planning on submitting FUSE for inclusion into 2.7 (and maybe 2.6
    if that is acceptable). I feel that FUSE has been maturing lately
    with some very interesting applications [1].

    Here are the reasons for _not_ including it:

     1) There are already two filesystems in kernel that are perfectly
        usable for this purpose: NFS and CODA

     2) There are currently two competing userspace filesystem layers that
        have about the same "market share": LUFS and FUSE. Why should we
        prefer one over the other

    I'll try to refute myself on these points:

     1) Both NFS and CODA were designed for something different. IOW they
        are not optimized for the purpose of supporting userspace
        filesystems. NFS is slow and there are problems with coherency of
        the underlying and the mounted filesystem. CODA does not support
        random file access (or even streaming), only reading whole files.
        It also has a miriad of small problems when used for exporting a
        userspace fs (I've been personally burned many times while doing
        AVFS over CODA).

     2) This one is harder to get rid of, especially because I don't want
        to delve into the technical merits of one or the other (I'd be a
        bit biased). But I have compared both the kernel interface and
        the library API of LUFS and FUSE and they are very similar. And
        that is a good thing, because it makes possible to support LUFS
        filesystems with the FUSE kernel module and vica versa.

    Miklos

    [1] For a list of applications using FUSE see:

       <http://www.inf.bme.hu/~mszeredi/fuse/Filesystems>
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Voicu Liviu: "Re: Official NVIDIA drivers for 2.6"

    Relevant Pages

    • [ANNOUNCE] Filesystem in Userspace (FUSE) 1.1 stable version
      ... This release adds support for the 2.6 Linux kernel series. ... features include support for exporting FUSE filesystems over NFS, ... makes the creation of filesystems in userspace very easy. ...
      (Linux-Kernel)
    • Disk sync at shutdown and fusefs filesystems
      ... improving performance as there isn't a block device cache in the ... kernel, and it was originally made in Linux with that assumption. ... The problem with NTFS-3G (and all other FUSE based drivers maybe) is ... Generally this isn't a problem since most FUSE filesystems are ...
      (freebsd-hackers)
    • Re: [PATCH 0/7] OMFS filesystem version 3
      ... Yes, that's quite annoying as FUSE doesn't work with my architecture, ... so I can't use the only good NTFS driver.... ... you mean without having to run the whole kernel around the ... that's a bit more tricky: filesystems use not just ...
      (Linux-Kernel)
    • Re: [fuse-devel] Merging?
      ... There's been sort of an increasing hype around userspace filesystems ... Apart from projects "officially" using fuse, ... I know of another interface to proprietary protocol mp3 players where ... we need fuse to be distributed in the kernel so that people is ...
      (Linux-Kernel)
    • Re: Fw: 2.6.23-rc3-mm1 UnionFS "BUG: atomic counter underflow"
      ... I compiled the kernel on an Ubuntu host. ... enabled multiprocessor or large memory support. ... # Firmware Drivers ...
      (Linux-Kernel)