On Fri, Jan 7, 2011 at 9:41 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Fri, Jan 7, 2011 at 7:26 AM, Ted Ts'o <tytso@xxxxxxx> wrote: >> Am I missing something? The kernel stores up to 3k worth of data, on >> a 4k block file system. Whereas e2fsck patch blindly assume 2k worhth >> of data regardless of the block size. The kernel patch looks ok, but >> the e2fsprogs patch seems badly broken.... So it's not badly broken, it copies blocksize-2K, which is clumsily written like this: + int len = ctx->fs->blocksize - 2*SUPERBLOCK_OFFSET; After that, only 4K block and 8K block will have a leftover, which will be copied from journal sb+1K to ext4 sb+1K. Yes, 2K blocks - no message buffer for you! The reason I am only copying 2K and throwing the extra K is this: print_message_buffer() is called from check_super_block(), *after* journal recovery, which was executed either by e2fsck itself or (and more likely in a errors=remount-ro situation) by ext4 on read-only mount. In the latter case, the extra K must be discarded, so I saw no reason to write special code for the first case. Neither did I find a good reason to complicate the recording code and limit it to record only blocksize-2K. >> >> - Ted >> > > I thought that ext4 super block on 4K block is 1K at offset 1K, so > kernel only uses the remaining 2K. > > It may very well be that e2fsck patch only works with 4K block size properly, > because I never tested it on other block sizes. > > Amir. > -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
