Re: [RFC] TileFS - a proposal for scalable integrity checking

["Jörn Engel" <joern@lazybastard.org>]

On Sun, 29 April 2007 07:57:18 -0500, Matt Mackall wrote:
> On Sun, Apr 29, 2007 at 02:21:13PM +0200, Jörn Engel wrote:
> 
> Thanks. I think this is a bit more direct solution than ChunkFS, but
> a) I haven't followed ChunkFS closely and b) I haven't been thinking
> about fsck very long, so this is still just a presented as fodder for
> discussion.

After thinking about it for a while, I believe you have a problem as
well.  Will cover that in a later mail.

> > You should add a 64bit fpos field.  That allows you to easily check for
> > addressing errors.
> 
> Describe the scenario where this manifests, please.

Block with checksum is written somewhere.  Block matches checksum, but a
bit flipped on the address bus.  To catch this you have to match 1)
block contents, 2) checksum and 3) inode tree.  ZFS does it by having
the checksum next to the block pointers in indirect blocks.  LogFS does
it by having a block header with checksum and (ino, pos, level) tupel.

Level is 0 for data blocks, 1 for indirect blocks, etc.  In the very
rare case that a data block gets written to the offset belonging to one
of its indirect blocks or vice versa this is necessary to catch the
error.  LogFS needs it for different reasons and I wouldn't mind if you
just ignore that detail.

> It just occurred to me that my approach is analogous to object-based
> rmap on the filesystem. The fpos proposal I think makes it more like
> the original per-pte rmap. This is not to say I think the same lessons
> apply, as I'm not clear what you're proposing yet.
> 
> Ooh.. I also just realized the tile approach allows much easier
> defragging/shrinking of large filesystems because finding the
> associated inode for blocks you want to move is fast.

It also allows for a background scan of the filesystem.  If data is
rotting on the medium, the only chance to detect this is by reading and
checking it.  Lots of data is never read from userspace, so it can
accumulate lots of errors.

Without rmap the filesystem cannot verify random blocks.

Jörn

-- 
Joern's library part 9:
http://www.scl.ameslab.gov/Publications/Gus/TwelveWays.html
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html