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

[Szabolcs Szakacsits <szaka@ntfs-3g.org>]

On Mon, 14 Apr 2008 Anton Altaparmakov wrote:
> On 14 Apr 2008, at 08:49, Andrew Morton wrote:
> > On Mon, 14 Apr 2008 09:25:46 +0200 Miklos Szeredi  <miklos@szeredi.hu>
> > wrote:
> > 
> > > And I didn't advocate moving
> > > ntfs to fuse, still that was done and the resulting filesystem at the
> > > moment happens to outperform the kernel one in every respect ;)
> > 
> > Gad.  Why?

Well, not only the kernel ntfs (in metadata operations) but also XFS, JFS, 
ext2 in metadata operations, ext3 in large bulk writes on commodity 
hardware.

It's also important to note that ntfs-3g isn't optimized yet at all. There 
are several major performance bootlenecks still in the kernel, FUSE and 
ntfs-3g itself.

Answering the why, the issue is almost never the context switch but the 
file system design and the quality of the implementation. While the latter 
still needs a lot of work on several areas (the size of the Microsoft NTFS 
driver is almost like all the in-kernel file system altogether) but the 
design can very nicely compensate the latter. E.g. ntfs (and ntfs-3g) 
already supports almost all the things what ext4 will include.

> No-one has "moved" ntfs to fuse.  

Yes, historically the user space ntfs code was moved to the kernel. The 
kernel always lagged somehow behind when this work was stopped a few years 
ago.

> However the kernel one as available in the kernel source tree doesn't 
> have many write-features, it can only overwrite files, it cannot 
> create/delete files, etc.  So I guess if you define "performance" to mean 
> "features" then sure ntfsmount/ntfs-3g have more features than the public 
> kernel driver.  If you define "performance" to mean "speed" then no 
> ntfsmount/ntfs-3g can't compare to the kernel except in very limited and 
> meaningless benchmarks...

First comes reliability for ntfs-3g. There are just too many million users. 
This is non-negotiable. Because of this, ntfs-3g is indeed not optimized 
yet. 

However the bootlenecks are almost always storage related (seeks, 
bandwidth, buses) on commodity desktop systems. Embedded devices and 
servers come a bit later with the CPU usage optimizations.

> btw. even comparing features, the fuse solutions lag behind in some  respects,
> e.g. no-one can "kill -9" the kernel driver 

I consider this as a benefit for FUSE file systems. An unloadable kernel 
module results reboot which is much more intrusive.

> leaving a corrupt file system on the volume 

That would be a file system driver implementation bug. What I never denied 
for ntfs-3g. Surely it's solvable but this was never a priority based on 
user wishes.

> (and under no-one I include the OOM killer for example!) 

The OOM killer can be configured and if the fs still uses too much memory 
then probably it's better to be killed/restarted with journaling support.
The important here would be the kernel finally fixing the non-sync behavior 
when it clams to do so (see recent kernel threads).

On the other hand, when in-kernel drivers leak then you get a system 
panic. 

> and another example is that the fuse solutions require large amounts of 
> ram whereas the kernel driver can happily function in 1MiB ram 

A FUSE driver can also happily function in much less than 1 MB RAM.

> when they find a large directory and the user has only 32MiB ram for 
> example...  

This is a FUSE fs implementation, not FUSE problem.

	Szaka

--
NTFS-3G:  http://ntfs-3g.org