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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
