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

[Matt Mackall <mpm@selenic.com>]

On Sun, Apr 29, 2007 at 06:34:59PM +0200, Andi Kleen wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
> > 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.
> 
> Problem I see is that your scheme doesn't support metadata checksums only.
> IMHO those are the most interesting because they have the potential
> to be basically zero cost, unlike full data checksumming.
> And doing metadata checksums is enough to handle the fsck
> problem.

It does. Checksums are not in any way an essential part of this
approach. We can checksum nothing, just metadata, or everything.

Further, we might find ourselves wanting to change the setting, so
we'd probably just want to leave slots in the tile headers for CRCs
always. So for now, let's imagine three mount options: nocrc, crc, and
metacrc.

> I'm sure there are many cases where full checksumming makes sense too,
> but those shouldn't be forced on everybody because it will slow down
> some important workloads (like O_DIRECT)

Right.

> Metadata checksums would be best just put into the file systems
> data structures. Essentially every object (inode, extent, directory entry,
> super block) should have a checksum that can be incrementially updated.

Putting CRCs on extents is trouble. You can't validate them without
reading the whole extent and writing into the middle of an extent is
also hard.

But this is kind of a rat-hole. The more immediate question is do the
reverse mapping pointers make sense for fsck purposes?

-- 
Mathematics is the supreme nostalgia of our time.