On Tue, Oct 08, 2013 at 12:03:31PM -0400, Theodore Ts'o wrote: > On Mon, Sep 30, 2013 at 06:28:37PM -0700, Darrick J. Wong wrote: > > Currently, the badblocks code assumes 32-bit block numbers. This leads to > > unfortunate results, because feeding a badblocks file to mke2fs with 64-bit > > block numbers causes libext2fs to rip off the upper 32 bits of the block number > > and then assign a truncated block number to the badblocks file. > > > > This is just as well, since the code that writes to the bb inode doesn't know > > about extents anyway. Rather than continuing to open-code block map > > manipulation, simply use existing library functions to truncate the old bb > > inode, mark all badblocks in use, and then assign them to the badblocks file. > > We can even use extents now. > > > > (It's arguable that badblocks is a vestigial organ now, but perhaps someone is > > using it? I use it to stress-test disk block allocation, but I might just be > > nutty.) > > > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > Yeah, I think badblocks is vestigal at this point, and for huge disk > arrays, almost certainly block replacement will be handed at the LVM, > storage array, or HDD level. So it might be better simply to have > mke2fs throw an error if there is an attempt to hand it a 64-bit block > number. Ok. I'll audit all callers of ext2fs_badblocks_list_add() to make sure they reject > 2^32 numbers. --D > > - Ted > -- > 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 -- 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
