Re: topics for the file system mini-summit

[Matthew Wilcox <matthew@wil.cx>]

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.  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?

The obvious answer is to put a special flag on the continued inode ...
but then the question becomes more about the care and feeding of
said flag.  Maybe it's a counter.  But then fsck needs to check the
counter's not corrupt.  Or is it backlinks from the inode to all its
continuation inodes?  That quickly gets messy with locking.

Surely XFS must have a more elegant solution than this?