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