From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valerie Henson Subject: Re: topics for the file system mini-summit Date: Wed, 31 May 2006 20:24:18 -0700 Message-ID: <20060601032418.GM10420@goober> References: <44762552.8000906@emc.com> <20060601021908.GL10420@goober> <20060601024247.GB32143@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ric Wheeler , linux-fsdevel@vger.kernel.org, Arjan van de Ven Return-path: Received: from fmr17.intel.com ([134.134.136.16]:21181 "EHLO orsfmr002.jf.intel.com") by vger.kernel.org with ESMTP id S1751680AbWFADZW (ORCPT ); Wed, 31 May 2006 23:25:22 -0400 To: Matthew Wilcox Content-Disposition: inline In-Reply-To: <20060601024247.GB32143@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, May 31, 2006 at 08:42:47PM -0600, Matthew Wilcox wrote: > On Wed, May 31, 2006 at 07:19:09PM -0700, Valerie Henson wrote: > > I don't think a block group is a good enough fault isolation domain - > > think hard links. What I think we need is normal file system > > structures when you are referencing stuff inside your fault isolation > > domain, and something more complicated if you have to reference stuff > > outside. One of Arjan's ideas involves something we're calling > > continuation inodes - if the file's data is stored in multiple > > domains, it has a separate continuation inode in each domain, and each > > continuation inode has all the information necessary to run a full > > fsck on the data inside that domain. Similarly, if a directory has a > > hard link to a file outside its domain, we'll have to allocate a > > continuation inode and dir entry block in the domain containing the > > file. The idea is that you can run fsck on a domain without having to > > go look outside that domain. You may have to clean up a few things in > > other domains, but they are easy to find and don't require an fsck in > > other domains. > > I don't quite get it. Let's say we have directories A and B in domain A > and domain B. A file C is created in directory B and is thus allocated > in domain B. Now we create a link to file C in directory A, and remove > the link from directory B. All correct up to here... > Presumably we have a continuation inode in > domain A and an inode with no references to it in domain B. How does > fsck tell that there's a continuation inode in a different domain? Actually, the continuation inode is in B. When we create a link in directory A to file C, a continuation inode for directory A is created in domain B, and a block containing the link to file C is allocated inside domain B as well. So there is no continuation inode in domain A. That being said, this idea is at the hand-waving stage and probably has many other (hopefully non-fatal) flaws. Thanks for taking a look! > Surely XFS must have a more elegant solution than this? val@goober:/usr/src/linux-2.6.16.19$ wc -l `find fs/xfs/ -type f` [snip] 109083 total :) -VAL