On Sun, 13 Apr 2008, Christoph Hellwig wrote:
quoted text
> > 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.

quoted text
> 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 
    this.

 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.

quoted text
> 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.

	Szaka

-- 
NTFS-3G:  http://ntfs-3g.org
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html