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

[Anton Altaparmakov]

Hi,

On 14 Apr 2008, at 08:49, Andrew Morton wrote:
> On Mon, 14 Apr 2008 09:25:46 +0200 Miklos Szeredi  
> <miklos@xxxxxxxxxx> 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?

Miklos has the wrong end of the stick.  No-one has "moved" ntfs to  
fuse.  And the fuse implementation doesn't outperform the kernel  
implementation in anything at all.  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...

btw. even comparing features, the fuse solutions lag behind in some  
respects, e.g. no-one can "kill -9" the kernel driver leaving a  
corrupt file system on the volume (and under no-one I include the OOM  
killer for example!) and another example is that the fuse solutions  
require large amounts of ram whereas the kernel driver can happily  
function in 1MiB ram and less even as everything is in the page cache  
so it will just cause heavy paging whilst the fuse solutions just blow  
up / OOM the machine when they find a large directory and the user has  
only 32MiB ram for example...  At least I have seen reports of this on  
the mailing lists, not that I have ever cared to try.

Best regards,

	Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/