From owner-freebsd-stable@FreeBSD.ORG Mon Feb 13 13:28:41 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 59E1C1065673; Mon, 13 Feb 2012 13:28:41 +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 D60118FC1A; Mon, 13 Feb 2012 13:28:40 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rwvx7-0005F8-Uw; Mon, 13 Feb 2012 08:28:21 -0500 Date: Mon, 13 Feb 2012 08:28:21 -0500 From: Gary Palmer To: Alex Samorukov Message-ID: <20120213132821.GA78733@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F38AF69.6010506@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 13:28:41 -0000 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 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. Gary