From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 15:37:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8833106566B; Mon, 13 Feb 2012 15:37:04 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 966438FC18; Mon, 13 Feb 2012 15:37:04 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RwxxQ-0005Qx-TB; Mon, 13 Feb 2012 10:36:48 -0500 Date: Mon, 13 Feb 2012 10:36:48 -0500 From: Gary Palmer To: Alex Samorukov Message-ID: <20120213153648.GB78733@in-addr.com> References: <4F215A99.8020003@os2.kiev.ua> <4F27C04F.7020400@omnilan.de> <4F27C7C7.3060807@os2.kiev.ua> <4F37F81E.7070100@os2.kiev.ua> <4F38AF69.6010506@os2.kiev.ua> <20120213132821.GA78733@in-addr.com> <4F39233C.9090600@os2.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F39233C.9090600@os2.kiev.ua> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Harald Schmalzbauer , Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: disk devices speed is ugly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 15:37:05 -0000 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