On 02/13/2012 02:28 PM, Gary Palmer wrote:

Yes. But it will nit fix non-cached access to the disk (raw) devices. And
this is the main reason why ntfs-3g and exfat are much slower then working
on Linux.
But _that_ can be fixed with the appropriate application of a sensible
caching layer.
With every application?  :) Are you know anyone who wants to do this? At
least for 3 fuse filesystems.
The filesystem is the *BEST* place to do caching.  It knows what metadata
is most effective to cache and what other data (e.g. file contents) doesn't
need to be cached.  Any attempt to do this in layers between the FS and
the disk won't achieve the same gains as a properly written filesystem.
e.g. in a UFS implementation the disk layer may see a lot of I/Os for
blocks, not necessarily sequential, as a program lists a directory and stats
all the files which pulls in the inode tables.  The filesystem knows that it
needs the inode tables and is likely to need not only the current inode table
disk block but subsequent ones also, and instead of requesting the disk sector
that it needs to service the immediate stat(2) request but maybe the next few
also.  Without that insight into whats going on it is difficult to see how a
highly effective cache could be done at the geom layer.
I think we are playing in a "captain obvious".

I have nothing against statement that FS is a "best place for caching". Also - i am absolutely sure that its better to have kernel space fs driver then FUSE one.

But unfortunately there is no kernel space driver for the exfat, kernel driver for ntfs is ugly and buggy (and r/o) and i don`t think that anyone is going to change this.

And i really don`t understand why are you trying to tell that it cannot be effective when its so easy to proof that it can. Just try this with fuse based filesystems in Linux, and you will get speed compared to underlying device (especially on relatively slow USB devices). Then try the same code on FreeBSD to see how ugly things are.

And yes, in ideal world ever fs needs to have good written cache implementation and kernel should not care about caching raw devices at all. But as i mentioned before - there is no kernel-space drivers with a good cache implementation for this 2 widely used systems (and probably not only). Linux is a good example that device-level caching works, and works fine.

_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to