On Sun, Apr 29, 2007 at 02:21:13PM +0200, J??rn Engel wrote:
> On Sat, 28 April 2007 17:05:22 -0500, Matt Mackall wrote:
> >
> > This is a relatively simple scheme for making a filesystem with
> > incremental online consistency checks of both data and metadata.
> > Overhead can be well under 1% disk space and CPU overhead may also be
> > very small, while greatly improving filesystem integrity.
>
> I like it a lot. Until now it appears to solve more problems and cause
> fewer new problems than ChunkFS.
I like it too, especially the rmap stuff, but I don't think it solves
some of the problems chunkfs solves. The really nice thing about
chunkfs is that it tries hard to isolate each chunk from all the other
chunks. You can think of regular file systems as an OS one big shared
address space - any process can potentially modify any other process's
address space, including the kernel's - and chunkfs as the modern UNIX
private address space model. Except in rare worst case models (the
equivalent of a kernel bug or writing /dev/mem), the only way one
chunk can affect another chunk is through the narrow little interface
of the continuation inode. This severely limits the ability of one
chunk to corrupt another - the worse you can do is end up with the
wrong link count on an inode pointed to from another chunk.
I'm a big fan of the inode backpointers with directory-entry linked
list idea - so much so that I came up with it too. :) With regard to
rmap for blocks, I've been assuming that a chunk-level rmap is good
enough for what I want to do ("Who owns this block? Anyone?" during
fsck). If not, I'm all over the per-block rmap idea.
Overall, great ideas!
-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
