On Wed, Sep 10, 2014 at 05:10:21PM -0400, TR Reardon wrote: > > Date: Wed, 10 Sep 2014 13:48:40 -0700 > > From: darrick.wong@xxxxxxxxxx > > To: thomas_reardon@xxxxxxxxxxx > > CC: linux-ext4@xxxxxxxxxxxxxxx > > Subject: Re: tune2fs -O ^metadata_csum not checking bitmap failures > > > > On Wed, Sep 10, 2014 at 04:30:41PM -0400, TR Reardon wrote: > >> When running tune2fs -O ^metadata_csum, disable_uninit_bg() is called to > >> reset the gdt. However, return value is not checked, which allows a failure > >> (say, a block bitmap failure somewhere, among other errors) to continue > >> through to rewrite_metadata_checksums() > >> > >> This seems wrong; should not the rewrite occur only if > >> disable/enable_uninit_bg() succeeds? > > > > The rewrite will fail if either of the error cases in disable_uninit_bg() fail, > > since rewrite_metadata_checksums() also tries to load the bitmap and scan the > > inodes. > > Actually, rewrite_metadata_checksums() loads the bitmap with checksums OFF, > which in the test I just ran, will succeed. This leaves the fs in a weird > half-checksummed state. Icky. :( > I should have been clearer above: if the initial disable_uninit_bg() failure > occurs because of a *checksum error*, then we get into this confused state. > Given that people would possibly try to disable metadata_csum if there are > checksum errors, this seems like a fairly common scenario. I would say that if you have checksum errors you ought to run e2fsck, not just tape over the warning light... ...though if you're prepared to deal with the fallout/really know what you're doing, you can nuke the feature bit with 'feature ^metadata_csum' in debugfs. In any case, we ought to avoid tune2fs writing junk to a broken fs. --D > > > -- > 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
