On Fri, Jul 18, 2014 at 03:53:28PM -0700, Darrick J. Wong wrote: > If we encounter an inode with IND/DIND/TIND blocks or internal extent > tree blocks that point into critical FS metadata such as the > superblock, the group descriptors, the bitmaps, or the inode table, > it's quite possible that the validation code for those blocks is not > going to like what it finds, and it'll ask to try to fix the block. > Unfortunately, this happens before duplicate block processing (pass > 1b), which means that we can end up doing stupid things like writing > extent blocks into the inode table, which multiplies e2fsck' > destructive effect and can render a filesystem unfixable. > > To solve this, create a bitmap of all the critical FS metadata. If > before pass1b runs (basically check_blocks) we find a metadata block > that points into these critical regions, continue processing that > block, but avoid making any modifications, because we could be > misinterpreting inodes as block maps. Pass 1b will find the > multiply-owned blocks and fix that situation, which means that we can > then restart e2fsck from the beginning and actually fix whatever > problems we find. > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> Thanks, applied. - 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
