On Sun, Apr 29, 2007 at 06:34:59PM +0200, Andi Kleen wrote: > Matt Mackall <mpm@xxxxxxxxxxx> 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. - 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
