On Fri, Jan 7, 2011 at 9:41 PM, Amir Goldstein [off-list ref] wrote:

On Fri, Jan 7, 2011 at 7:26 AM, Ted Ts'o [off-list ref] wrote:

quoted

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.

quoted

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