Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Feb 2012 10:36:48 -0500
From:      Gary Palmer <gpalmer@freebsd.org>
To:        Alex Samorukov <ml@os2.kiev.ua>
Cc:        Harald Schmalzbauer <h.schmalzbauer@omnilan.de>, Adrian Chadd <adrian@freebsd.org>, freebsd-stable@freebsd.org
Subject:   Re: disk devices speed is ugly
Message-ID:  <20120213153648.GB78733@in-addr.com>
In-Reply-To: <4F39233C.9090600@os2.kiev.ua>
References:  <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <CAJ-VmomezUWrEgxxmUEOhWnmLDohMAWRpSXmTR=n2y_LuizKJg@mail.gmail.com> <4F37F81E.7070100@os2.kiev.ua> <CAJ-Vmok9Ph1sgFCy6kNT4XR14grTLvG9M3JvT9eVBRjgqD%2BY9g@mail.gmail.com> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <4F39233C.9090600@os2.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 13, 2012 at 03:50:36PM +0100, Alex Samorukov wrote:
> 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.

Please re-read my message.  At no time did I say that caching below the
FS could not provide speed improvements.  I said it could not be as
effective as a properly implemented filesystem.  I'm sure if you throw
memory at it, a geom layer cache can provide substantial speed ups.  However
I strongly suspect that a proper FS cache would provide a better memory/hit
ratio than a geom layer cache.

Gary



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120213153648.GB78733>