* tune2fs -O ^metadata_csum not checking bitmap failures @ 2014-09-10 20:30 TR Reardon 2014-09-10 20:48 ` Darrick J. Wong 0 siblings, 1 reply; 4+ messages in thread From: TR Reardon @ 2014-09-10 20:30 UTC (permalink / raw) To: darrick.wong@oracle.com, linux-ext4@vger.kernel.org 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? +Reardon -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: tune2fs -O ^metadata_csum not checking bitmap failures 2014-09-10 20:30 tune2fs -O ^metadata_csum not checking bitmap failures TR Reardon @ 2014-09-10 20:48 ` Darrick J. Wong 2014-09-10 21:10 ` TR Reardon 0 siblings, 1 reply; 4+ messages in thread From: Darrick J. Wong @ 2014-09-10 20:48 UTC (permalink / raw) To: TR Reardon; +Cc: linux-ext4@vger.kernel.org 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. However, I wouldn't want to guarantee that in perpetuity, so let's check the error codes anyway. --D > > +Reardon -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: tune2fs -O ^metadata_csum not checking bitmap failures 2014-09-10 20:48 ` Darrick J. Wong @ 2014-09-10 21:10 ` TR Reardon 2014-09-10 21:16 ` Darrick J. Wong 0 siblings, 1 reply; 4+ messages in thread From: TR Reardon @ 2014-09-10 21:10 UTC (permalink / raw) To: Darrick J. Wong; +Cc: linux-ext4@vger.kernel.org > Date: Wed, 10 Sep 2014 13:48:40 -0700 > From: darrick.wong@oracle.com > To: thomas_reardon@hotmail.com > CC: linux-ext4@vger.kernel.org > 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. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: tune2fs -O ^metadata_csum not checking bitmap failures 2014-09-10 21:10 ` TR Reardon @ 2014-09-10 21:16 ` Darrick J. Wong 0 siblings, 0 replies; 4+ messages in thread From: Darrick J. Wong @ 2014-09-10 21:16 UTC (permalink / raw) To: TR Reardon; +Cc: linux-ext4@vger.kernel.org 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@oracle.com > > To: thomas_reardon@hotmail.com > > CC: linux-ext4@vger.kernel.org > > 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@vger.kernel.org > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-09-10 21:16 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-09-10 20:30 tune2fs -O ^metadata_csum not checking bitmap failures TR Reardon 2014-09-10 20:48 ` Darrick J. Wong 2014-09-10 21:10 ` TR Reardon 2014-09-10 21:16 ` Darrick J. Wong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).