On Fri, Sep 11, 2009 at 07:57:00PM +0200, Damien Guibouret wrote: > > I have looked at the new features provided by ext4 and have a question > on flex_bg information initialization: > into ext4_fill_flex_info function of fs/ext4/super.c (lines 1698, 1700 > and 1702 for kernel 2.6.31) doesn't the atomic_set calls be atomic_add > to sum statistics of each group composing a flex group, or do I > misunderstand something ? Good eye; that's a bug; thanks for pointing that out. > For the extension to manage 48 bits blocks number, I do not see anything > to treat this for resize and bad inodes into kernel or e2fsprogs. For > the resize inode, it is perhaps an incompatibility of this feature with > 48 bits blocks number, but for the bad inode ? There is a plan for how to handle online resizing for > 2^32 block filesystems, but it hasn't been implemented yet. The basic support for it is there; that's what the META_BG feature is designed to support, so existing kernels will be able to deal with resized large filesystemes. But the code to actually do the on-line resizing hasn't been implemented yet. For the bad block inode, the solution is to make it be extent mapped inode. This also hasn't been implemented yet, but this is a much simpler one to write. The main reason why we haven't is that modern disks rarely have system-visible bad blocks; normally the hard drive has its own bad block remapping layer in hardware so we never see a bad block until the disk is failing so badly it needs to be replaced ASAP. - 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
