Just sent a patch related to this. Some more background: I observed this on a 1K block filesystem that I resized from 16 GB to 24 GB. Prior to the resize there were no remaining reserved GDT blocks. Possibly related to this issue, or possibly due to unrelated corruption, the filesystem errored and remounted read only. I rebooted and fsck'ed and discovered the corruption to be substantial. Unfortunately I don't have a block-level backup of the original state of the filesystem, the errors from before the reboot, or a log of what the initial fsck did. (I don't think that I let it do much, if anything, more than try to replay the journal, which was not successful.) What I found in debugfs was that: * The descriptor data for groups 0..31 instead described groups 3040..3071. * The descriptor data for groups 2048..3071 was zero'ed (except checksum) The first bullet is what gave me the idea that the new descriptors were being written in the wrong place. But I don't have a solid explanation for the second bullet. I tried similar resizes to the original with debugging enabled before and after my proposed fix, and the "updating metadata backup" messages are consistent with the explanation. Before the fix, every meta_bg backup goes to blocks 8194 and 253953. 8194 is a backup copy of the first descriptor block, explaining why groups 0..31 were overwritten (assuming fsck tried to use the first backup copy). 253953 contains a block bitmap, and doing an fsck immediately after the resize finds a bunch of block bitmap inconsistencies. -- 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
