Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck

David Chinner
2007-04-25T10:55:29Z

On Tue, Apr 24, 2007 at 04:53:11PM -0500, Amit Gud wrote:
> Nikita Danilov wrote:
> >Maybe I failed to describe the problem presicely.
> >
> >Suppose that all chunks have been checked. After that, for every inode
> >I0 having continuations I1, I2, ... In, one has to check that every
> >logical block is presented in at most one of these inodes. For this one
> >has to read I0, with all its indirect (double-indirect, triple-indirect)
> >blocks, then read I1 with all its indirect blocks, etc. And to repeat
> >this for every inode with continuations.
> >
> >In the worst case (every inode has a continuation in every chunk) this
> >obviously is as bad as un-chunked fsck. But even in the average case,
> >total amount of io necessary for this operation is proportional to the
> >_total_ file system size, rather than to the chunk size.
> >
>
> Perhaps, I should talk about how continuation inodes are managed /
> located on disk. (This is how it is in my current implementation)
>
> Right now, there is no distinction between an inode and continuation
> inode (also referred to as 'cnode' below), except for the
> EXT2_IS_CONT_FL flag. Every inode holds a list of static number of
> inodes, currently limited to 4.
>
> The structure looks like this:
>
> ---------- ----------
> | cnode 0 |---------->| cnode 0 |----------> to another cnode or NULL
> ---------- ----------
> | cnode 1 |----- | cnode 1 |-----
> ---------- | ---------- |
> | cnode 2 |-- | | cnode 2 |-- |
> ---------- | | ---------- | |
> | cnode 3 | | | | cnode 3 | | |
> ---------- | | ---------- | |
> | | | | | |
>
> inodes inodes or NULL

How do you recover if fsfuzzer takes out a cnode in the chain? The
chunk is marked clean, but clearly corrupted and needs fixing and
you don't know what it was pointing at. Hence you have a pointer to
a trashed cnode *somewhere* that you need to find and fix, and a
bunch of orphaned cnodes that nobody points to *somewhere else* in
the filesystem that you have to find. That's a full scan fsck case,
isn't?

It seems that any sort of damage to the underlying storage (e.g.
media error, I/O error or user brain explosion) results in the need
to do a full fsck and hence chunkfs gives you no benefit in this
case.

Cheers,

Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group