On Wed, 2 May 2007 10:37:38 -0500, Matt Mackall wrote: > > fpos does allow us to check just a subset of the file efficiently, > yes. And that things are more strictly 1:1, because it unambiguously > matches a single forward pointer in the file. Ok, I'm warming to the > idea. > > But indirect blocks don't have an fpos, per se. They'd need a special > encoding. As the fpos entries will all be block aligned, we'll have 12 > extra bits to play with, so that may be easy enough. No special encoding is needed. LogFS uses the fpos of some block behind that indirect block. It doesn't even matter which one. When checking the block, the indirect block has to get touched while trying to get to the alledged fpos. As already explained, LogFS also encodes the level (data, indirect, doubly indirect, etc.). If you want to play games with extra bits, you could do the same. Two bits should be sufficient for ext2. The only thing the level buys you for TileFS is to detect writes to the wrong address, where wrong address and correct address match in (ino, fpos), but not in level. > It's a bit frustrating to have 96-bit (inode+fpos) pointers in one > direction and 32-bit (blockno) pointers in the other though. This > doubles the overhead to .4%. Still not fatal - regular ext2 overhead > is somewhere between 1% and 3% depending on inode usage. My ext3 root partition currently wastes 60 Bytes per block on unused inodes. If space was an issue, adding an inode file to to TileFS would help more than trying to squeeze bits from the rmap. Jörn -- /* Keep these two variables together */ int bar; - 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
