On Sun, Apr 29, 2007 at 05:58:48PM +0200, Jörn Engel wrote: > On Sat, 28 April 2007 17:05:22 -0500, Matt Mackall wrote: > > > > Some things we need to check during fsck: > > > > all directories point to in-use inodes > > all in-use inodes are referred to by directories > > all inodes in use are marked in use > > all free inodes are marked free > > all inodes point to in-use blocks > > all inode refcounts are correct > > all inode block counts are correct > > free inode count is correct > > > > no blocks are used twice > > all used blocks are marked as used > > all free blocks are marked as free > > optional: all block contents are correct > > statfs information matches filesystem content > > This one may still require a full fsck in your current approach. One if > the good aspects of ChunkFS (assuming my understanding matches reality) > is to have per-chunk counters for free blocks, free inodes, etc. For a > fast fsck you would need to have these counters per-unit as well. It > doesn't matter whether your unit is a tile, chunk, blockgroup or > karboozel. Yes. This is probably not a very big problem. Once we've checked all the tiles in a block group and they're clean, we know that block and inode bitmaps are correct, so we can doublecheck the per-blockgroup counters. One obvious approach is simply batching a blockgroup's worth of tiles at a time (if tile header entries are 64 bits, then there are 64 tiles in a block group). Then you keep running totals and check at the end. Memory usage is still O(single tile). Summing blockgroup totals across a million block groups.. we'll probably want something like: > Having some tree structure for these counters would also help. Statfs > requires to add all counters for all units. Smaller units speed up fsck > but slow down statfs. With a tree statfs can be O(log(n)). -- 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
