linux-kernel - Re: [PATCH 0/7] OMFS filesystem version 3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Apr 2008 15:46:00 +0300 (MET DST)
From:	Szabolcs Szakacsits <szaka@...s-3g.org>
To:	Christoph Hellwig <hch@...radead.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Bob Copeland <me@...copeland.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [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 
    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.

> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/