From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Theodore Tso <tytso@mit.edu>,
Sunil Mushran <sunil.mushran@oracle.com>,
Martin K Petersen <martin.petersen@oracle.com>,
Greg Freemyer <greg.freemyer@gmail.com>,
Amir Goldstein <amir73il@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andi Kleen <andi@firstfloor.org>, Mingming Cao <cmm@us.ibm.com>,
Joel Becker <jlbec@evilplan.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-ext4@vger.kernel.org, Coly Li <colyli@gmail.com>
Subject: Re: [PATCH 15/28] ext4: Calculate and verify block bitmap checksum
Date: Wed, 9 Nov 2011 16:57:12 -0800 [thread overview]
Message-ID: <20111110005656.GX12447@tux1.beaverton.ibm.com> (raw)
In-Reply-To: <EEB33371-CE71-4283-A5B1-E09083F08DCB@dilger.ca>
On Mon, Nov 07, 2011 at 02:44:02PM -0700, Andreas Dilger wrote:
> On 2011-11-07, at 1:00 PM, Darrick J. Wong wrote:
> > On Thu, Oct 13, 2011 at 12:16:31AM -0700, Darrick J. Wong wrote:
> >> On Wed, Oct 12, 2011 at 06:00:40PM -0600, Andreas Dilger wrote:
> >>> I've been thinking a while that we should add per-group error flags
> >>> for the block and inode bitmaps. That way, if we detect errors with
> >>> either one, we can set the flag in the group descriptor and avoid
> >>> using it for any allocations in the future. Otherwise, we try to
> >>> read the bitmap in repeatedly.
> >>
> >> I think there's some code in ext4 somewhere that does that. I also wonder if
> >> the possibility that we're seeing a transient corruption error is worth
> >> rechecking the block until it fails? (I suspect not, but I decided to throw
> >> that out there anyway.)
> >
> > There's a bit of code in ext4_init_block_bitmap that makes a block group
> > unwritable if the bg checksum fails to verify:
> >
> > /* If checksum is bad mark all blocks used to prevent allocation
> > * essentially implementing a per-group read-only flag. */
> > if (!ext4_group_desc_csum_verify(sbi, block_group, gdp)) {
> > ext4_error(sb, "Checksum bad for group %u",
> > block_group);
> > ext4_free_blks_set(sb, gdp, 0);
> > ext4_free_inodes_set(sb, gdp, 0);
> > ext4_itable_unused_set(sb, gdp, 0);
> > memset(bh->b_data, 0xff, sb->s_blocksize);
> > ext4_block_bitmap_csum_set(sb, block_group, gdp, bh,
> > EXT4_BLOCKS_PER_GROUP(sb) /
> > 8);
> > return 0;
> > }
> >
> > Do people think that doing this in the event of a block/inode bitmap checksum
> > failure is a good idea?
>
> For me, yes. The sanity checks we do on the block bitmaps are only very
> basic (e.g. bits for bitmaps themselves are set, for inode table). Blocking
> any allocation from a single group with a bad checksum is not harmful in the
> long term, and can avoid an explosion of corruption if blocks would otherwise
> be allocated multiple times.
On second thought, let's see what happens with groups that fail checksums ...
it seems that ext4_check_descriptors() fails the mount in the event of a group
descriptor failing checksum. Both ext4_read_inode_bitmap() and
ext4_read_block_bitmap() return NULL if the respective bitmap fails checksum.
It looks like most of ext4's block {de,}allocate functions will fail on NULL
bitmap pointer, so it shouldn't be possible to allocate (or deallocate) from a
broken group.
There is one small deficiency: we need an explicit flag that marks the group
dead. That way if either bitmap fails checksum, the other _bitmap_read()
function will know to just return NULL, and the group becomes totally frozen to
allocation activity.
I think ext4_new_inode need to be taught to continue scanning groups if it
encounters a "dead" group? I'm not sure yet if the same thing needs to be
applied to the block allocation code.
I'm actually wondering how it is that a group could pass checksum verification
at mount time but fail it later, which is what that code snippet seems designed
to catch. Maybe something related to online resize? Either way, I'm now
wondering if we really need something like that for the simple case of bitmaps
failing checksum. I think we're already covered, but maybe I missed something?
--D
>
> Cheers, Andreas
>
>
>
>
>
next prev parent reply other threads:[~2011-11-10 0:57 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-08 7:53 [PATCH v2 00/28] ext4: Add metadata checksumming Darrick J. Wong
2011-10-08 7:53 ` [PATCH 01/28] ext4: ext4_dx_add_entry should dirty directory metadata with the directory inode Darrick J. Wong
2011-10-08 7:53 ` [PATCH 02/28] ext4: ext4_rename should dirty dir_bh with the correct directory Darrick J. Wong
2011-10-08 7:54 ` [PATCH 03/28] ext4: ext4_mkdir should dirty dir_block with the parent inode Darrick J. Wong
2011-10-08 7:54 ` [PATCH 04/28] ext4: Prevent stack overrun in ext4_file_open when recording last known mountpoint Darrick J. Wong
2011-10-08 7:54 ` [PATCH 05/28] ext4: Fix endian problem in MMP initialization Darrick J. Wong
2011-10-08 7:54 ` [PATCH 06/28] ext4: Create a new BH_Verified flag to avoid unnecessary metadata validation Darrick J. Wong
2011-10-08 7:54 ` [PATCH 07/28] ext4: Create a rocompat flag for extended metadata checksumming Darrick J. Wong
2011-10-08 7:54 ` [PATCH 08/28] ext4: Record the checksum algorithm in use in the superblock Darrick J. Wong
2011-10-08 7:54 ` [PATCH 09/28] ext4: Only call out to crc32c if necessary Darrick J. Wong
2011-10-08 7:54 ` [PATCH 10/28] ext4: Calculate and verify superblock checksum Darrick J. Wong
2011-10-08 7:54 ` [PATCH 11/28] ext4: Calculate and verify inode checksums Darrick J. Wong
2011-10-12 19:45 ` Andreas Dilger
2011-10-12 21:03 ` Darrick J. Wong
2011-10-13 0:02 ` Andreas Dilger
2011-10-08 7:55 ` [PATCH 12/28] ext4: Use i_generation in inode-related metadata checksums Darrick J. Wong
2011-10-12 19:52 ` Andreas Dilger
2011-10-12 21:28 ` Darrick J. Wong
2011-10-13 0:06 ` Andreas Dilger
2011-10-08 7:55 ` [PATCH 13/28] ext4: Create bitmap checksum helper functions Darrick J. Wong
2011-10-08 7:55 ` [PATCH 14/28] ext4: Calculate and verify checksums for inode bitmaps Darrick J. Wong
2011-10-08 7:55 ` [PATCH 15/28] ext4: Calculate and verify block bitmap checksum Darrick J. Wong
[not found] ` <AE869D1A-2A06-4849-8752-74924B0C05BD@dilger.ca>
2011-10-13 7:16 ` Darrick J. Wong
2011-11-07 20:00 ` Darrick J. Wong
2011-11-07 21:44 ` Andreas Dilger
2011-11-10 0:57 ` Darrick J. Wong [this message]
2011-11-10 2:34 ` Andreas Dilger
2011-10-08 7:55 ` [PATCH 16/28] ext4: Verify and calculate checksums for extent tree blocks Darrick J. Wong
2011-10-08 7:55 ` [PATCH 17/28] ext4: Calculate and verify checksums for htree nodes Darrick J. Wong
[not found] ` <F6453844-06CC-4245-BB39-EBA4327D4C92@dilger.ca>
2011-10-13 7:21 ` Darrick J. Wong
2011-10-08 7:55 ` [PATCH 18/28] ext4: Calculate and verify checksums of directory leaf blocks Darrick J. Wong
2011-10-08 7:55 ` [PATCH 19/28] ext4: Calculate and verify checksums of extended attribute blocks Darrick J. Wong
2011-10-08 7:55 ` [PATCH 20/28] ext4: Add new feature to make block group checksums use metadata_csum algorithm Darrick J. Wong
2011-10-08 7:56 ` [PATCH 21/28] ext4: Add checksums to the MMP block Darrick J. Wong
2011-10-08 7:56 ` [PATCH 22/28] jbd2: Update structure definitions and flags to support extended checksumming Darrick J. Wong
2011-10-08 7:56 ` [PATCH 23/28] jbd2: Grab a reference to the crc32c driver only when necessary Darrick J. Wong
2011-10-08 7:56 ` [PATCH 24/28] jbd2: Update structure definitions and flags to support extended checksumming Darrick J. Wong
2011-10-08 7:56 ` [PATCH 25/28] jbd2: Checksum revocation blocks Darrick J. Wong
2011-10-08 7:56 ` [PATCH 26/28] jbd2: Checksum descriptor blocks Darrick J. Wong
2011-10-08 7:56 ` [PATCH 27/28] jbd2: Checksum commit blocks Darrick J. Wong
2011-10-08 7:56 ` [PATCH 28/28] jbd2: Checksum data blocks that are stored in the journal Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111110005656.GX12447@tux1.beaverton.ibm.com \
--to=djwong@us.ibm.com \
--cc=adilger.kernel@dilger.ca \
--cc=amir73il@gmail.com \
--cc=andi@firstfloor.org \
--cc=cmm@us.ibm.com \
--cc=colyli@gmail.com \
--cc=greg.freemyer@gmail.com \
--cc=jlbec@evilplan.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sunil.mushran@oracle.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®