Date: Mon, 13 Feb 2012 15:50:36 +0100 From: Alex Samorukov <ml@os2.kiev.ua> To: Gary Palmer <gpalmer@freebsd.org> 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: <4F39233C.9090600@os2.kiev.ua> In-Reply-To: <20120213132821.GA78733@in-addr.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F39233C.9090600>