[lkml]   [2008]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/7] OMFS filesystem version 3

    On Sun, 13 Apr 2008, Christoph Hellwig wrote:
    > > I'm not complaining about anything. Who has?
    > >
    > > As the filesystem is for occasional, non-performance-sensitive use
    > > by a very small number of people, doing it via FUSE sounds like an
    > > all-round more practical approach. This has nothing to do with quality of
    > > implementation at all.
    > It's a stupid idea.

    FUSE is more than just providing a framework for block based filesystems.
    Sometimes FUSE is criticised for the extra useful features it provides.
    Sometimes the criticism comes from misunderstandings.

    > less efficient because of the additional context switches

    This is about as true as claiming FUSE doesn't have any context switch
    overhead. Sometimes it has none, sometimes small, sometimes it can be
    significant (e.g. when not using the 50 fold context switch speed up
    patch). The question is, how releavant it is? Just some short notes,

    1. Using the in-kernel cached data involves no context switch for FUSE.

    2. On commodity hardware Linux can do a million context switches.
    File system workloads barely need or can do more than a few tens
    of thousands file operations per second (fsops) due to storage
    bottlenecks. Which means maximum about only extra 5% CPU use for
    block based FUSE file systems.

    If they do more fsops then typically it's served from the kernel caches
    and no user space and context switches are involved at all.

    3. ext3 with the highly optimized dir_index is far the fastest
    traditional block based file system in file creation. Once I wrote
    a FUSE file system which apparently would have been faster if the
    VFS wouldn't do needlessly a lookup() before create(). AFAIK some
    network file systems have the some performance problem because of

    4. The dominant factors for performance is design, quality of the
    implementation and lead time to optimize for the (latest) hardware.
    What's the best way to realize this depends on many factors.

    5. Some workloads can indeed trigger very high context switches. This
    could be improved/solved but probably it would be more beneficial to
    improve context switch performance in software and hardware.

    > and harder to use because you need additional userspace packages and need
    > to setup fuse.

    The fuse install should solve all setup issues and a fuse fs can be written
    where the traditional commands work:

    mount -t fstype device mountpoint
    umount mountpoint

    Ntfs-3g doesn't even need fuse user space being installed, only a
    modprobeable fuse kernel module.



     \ /
      Last update: 2008-04-18 14:47    [W:0.022 / U:0.664 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site