disk devices speed is ugly

Gary Palmer gpalmer at freebsd.org
Mon Feb 13 13:28:41 UTC 2012

On Mon, Feb 13, 2012 at 07:36:25AM +0100, Alex Samorukov wrote:
> On 02/13/2012 06:27 AM, Adrian Chadd wrote:
> >On 12 February 2012 09:34, Alex Samorukov<ml at os2.kiev.ua>  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.


More information about the freebsd-stable mailing list