Re: topics for the file system mini-summit

[Valerie Henson <val_henson@linux.intel.com>]

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