On Fri, Jan 07, 2011 at 11:07:23PM +0200, Amir Goldstein wrote: > 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; So this should be: int len = ctx->fs->blocksize - SUPERBLOCK_OFFSET - sizeof (<superblock>); Although those two numbers are equal right now, there is no reason to assume that they will remain so in the future. So if the superblock size (or the offset) changes in the future, it's much better to have programmed this so that it will keep on working as opposed to getting to deal with ugly bugs in code that hasn't changed in years... Roger. -- ** R.E.Wolff@xxxxxxxxxxxx ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. Does it sit on the couch all day? Is it unemployed? Please be specific! Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ -- 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
