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: Mon, 7 Nov 2011 12:00:08 -0800 [thread overview]
Message-ID: <20111107200008.GW12447@tux1.beaverton.ibm.com> (raw)
In-Reply-To: <20111013071631.GQ12447@tux1.beaverton.ibm.com>
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:
> > On 2011-10-08, at 1:55 AM, Darrick J. Wong wrote:
> > > Compute and verify the checksum of the block bitmap; this checksum is
> > > stored in the block group descriptor.
> > >
> > > @@ -353,11 +360,26 @@ ext4_read_block_bitmap(struct super_block *sb, ext4_group_t block_group)
> > > /*
> > > * file system mounted not to panic on error,
> > > + * -EIO with corrupt bitmap
> > > */
> > > + ext4_lock_group(sb, block_group);
> > > + if (!ext4_valid_block_bitmap(sb, desc, block_group, bh) ||
> > > + !ext4_block_bitmap_csum_verify(sb, block_group, desc, bh,
> > > + EXT4_BLOCKS_PER_GROUP(sb) / 8)) {
> > > + ext4_unlock_group(sb, block_group);
> > > + put_bh(bh);
> > > + ext4_error(sb, "Corrupt block bitmap - block_group = %u, "
> > > + "block_bitmap = %llu", block_group, bitmap_blk);
> > > + return NULL;
> > > + }
> > > + ext4_unlock_group(sb, block_group);
> > > + set_buffer_verified(bh);
> >
> > 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?
--D
>
> > > @@ -803,6 +842,11 @@ static int ext4_mb_init_cache(struct page *page, char *incore)
> > > if (groups_per_page == 0)
> > > groups_per_page = 1;
> > >
> > > + csd = kzalloc(sizeof(struct ext4_csum_data) * groups_per_page,
> > > + GFP_NOFS);
> > > + if (csd == NULL)
> > > + goto out;
> > > +
> > > /* allocate buffer_heads to read bitmaps */
> > > if (groups_per_page > 1) {
> > > err = -ENOMEM;
> > > @@ -880,22 +924,25 @@ static int ext4_mb_init_cache(struct page *page, char *incore)
> > > * get set with buffer lock held.
> > > */
> > > set_bitmap_uptodate(bh[i]);
> > > - bh[i]->b_end_io = end_buffer_read_sync;
> > > + csd[i].cd_sb = sb;
> > > + csd[i].cd_group = first_group + i;
> > > + bh[i]->b_private = csd + i;
> > > + bh[i]->b_end_io = ext4_end_buffer_read_sync;
> >
> > It seems to be allocating this extra csd[] and calling the more complex
> > ext4_end_buffer_read_sync() callback regardless of whether the checksum
> > code is enabled or not. Would it be better to only set the custom
> > callback if we need to verify the checksum?
>
> Yep, we could go straight to end_buffer_read_sync in the no-csum case.
>
> --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
>
next prev parent reply other threads:[~2011-11-07 20:01 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 [this message]
2011-11-07 21:44 ` Andreas Dilger
2011-11-10 0:57 ` Darrick J. Wong
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=20111107200008.GW12447@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;
as well as URLs for NNTP newsgroup(s).