On Tue, Apr 03, 2012 at 01:28:14PM -0600, Andreas Dilger wrote: > It would probably not even cause the backup group descriptor to be > lost in the worst case (new mke2fs/e2fsck/resize2fs creates gd backup, > old e2fsck "deletes" gd backup block, use filesystem for a long time, > corrupt primary group descriptors, try to recover using new e2fsck). Well, it can only be repaired if that block hasn't been allocated and assigned to a file. If it has, then you can't easily repair it and you have to resign yourself to not having a backup of the bgd. And that means more complexity since e2fsck would have to deal with the possibility that the last block might contain a backup bgd, or might be allocated to a file. And even if there is a "harmless" corruption, it will still potentially alarm users who happen to format an ext4 file system with this this change implemented, and then they boot a rescue CD which is using an older e2fsprogs. Ultimately I suspect the best approach might be to simply try to reconstruct the last bgd by attempting to find the inode table in case the last meta_bg bgd is destroyed. Since this only comes up for file systems with a single block group in a meta_bg, it's a relatively easy thing to do..... - 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
