Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757618AbXH1O4H (ORCPT ); Tue, 28 Aug 2007 10:56:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753589AbXH1Ozv (ORCPT ); Tue, 28 Aug 2007 10:55:51 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:41488 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752655AbXH1Ozu (ORCPT ); Tue, 28 Aug 2007 10:55:50 -0400 Date: Wed, 29 Aug 2007 00:55:30 +1000 From: David Chinner To: Fengguang Wu Cc: David Chinner , Chris Mason , Andrew Morton , Ken Chen , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jens Axboe Subject: Re: [PATCH 0/6] writeback time order/delay fixes take 3 Message-ID: <20070828145530.GD61154114@sgi.com> References: <386910467.21100@ustc.edu.cn> <20070821202314.335e86ec@think.oraclecorp.com> <20070822011841.GA8090@mail.ustc.edu.cn> <20070823023306.GM61154114@sgi.com> <20070824135504.GA9029@mail.ustc.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070824135504.GA9029@mail.ustc.edu.cn> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1789 Lines: 42 On Fri, Aug 24, 2007 at 09:55:04PM +0800, Fengguang Wu wrote: > On Thu, Aug 23, 2007 at 12:33:06PM +1000, David Chinner wrote: > > On Wed, Aug 22, 2007 at 09:18:41AM +0800, Fengguang Wu wrote: > > > On Tue, Aug 21, 2007 at 08:23:14PM -0400, Chris Mason wrote: > > > Notes: > > > (1) I'm not sure inode number is correlated to disk location in > > > filesystems other than ext2/3/4. Or parent dir? > > > > The correspond to the exact location on disk on XFS. But, XFS has it's > > own inode clustering (see xfs_iflush) and it can't be moved up > > into the generic layers because of locking and integration into > > the transaction subsystem. > > > > > (2) It duplicates some function of elevators. Why is it necessary? > > > > The elevators have no clue as to how the filesystem might treat adjacent > > inodes. In XFS, inode clustering is a fundamental feature of the inode > > reading and writing and that is something no elevator can hope to > > acheive.... > > Thank you. That explains the linear write curve(perfect!) in Chris' graph. > > I wonder if XFS can benefit any more from the general writeback clustering. > How large would be a typical XFS cluster? Depends on inode size. typically they are 8k in size, so anything from 4-32 inodes. The inode writeback clustering is pretty tightly integrated into the transaction subsystem and has some intricate locking, so it's not likely to be easy (or perhaps even possible) to make it more generic. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/