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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
