disk devices speed is ugly

Alex Samorukov ml at os2.kiev.ua
Mon Feb 13 14:52:00 UTC 2012

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.

More information about the freebsd-stable mailing list