public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Akira Fujita <a-fujita@rs.jp.nec.com>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [BUG] e2fsprogs: e2fsck -b outputs checksum warnings
Date: Tue, 31 Jan 2012 15:56:57 -0500	[thread overview]
Message-ID: <20120131205657.GC25951@thunk.org> (raw)
In-Reply-To: <4F28527D.9030405@redhat.com>

On Tue, Jan 31, 2012 at 02:43:41PM -0600, Eric Sandeen wrote:
>         /*
>          * If recovery is from backup superblock, Clear _UNININT flags &
>          * reset bg_itable_unused to zero
>          */
> 
> This makes the group look like it is initialized and that all inodes
> are used.
> 
> Can someone remind me why we want to do this?

It's because the kernel don't update the backup block group
descriptors.  So there may very well be bitmaps that have since been
initialized and in use, and there may very well be inodes that have
been allocated that are not represented by the value of
bg_itable_unused in the backup bg descriptors.  And the inode iterator
functions will simply skip inodes that are marked as not in use;
indeed, that's one of the ways we speed up fsck times; by skipping
portions of the inode table that are not in use.  The problem is that
if the primary superblock and block group descriptors are corrupt, we
don't know which portions of the inode table are in use and which are
not.

This is also why the lazy itable init code is so important; if we're
going to skip zero'ing the inode table, then until the inode table
gets initialized, we are at risk of finding old inodes from previous
file systems that had been on the storage device in the case where we
are using backup bg descriptors and/or the checksums are incorrect.
This doesn't happen that often, but it's still important that the
inode table get appropriately initialized, which is why it may be ok
for a distro installer to disable the lazy itable init to speed up the
install process, but you still want to let the lazy itable process
finish up as soon as possible.

> > One or more block group descriptor checksums are invalid.  Fix<y>? yes
> > 
> > Group descriptor 0 checksum is invalid.  FIXED.
> > Group descriptor 1 checksum is invalid.  FIXED.
> > Group descriptor 2 checksum is invalid.  FIXED.
> > Group descriptor 3 checksum is invalid.  FIXED.

This is certainly scary, though.  In the case where we do need to use
the backup block group descriptors, it would be better to reset the
checksum to the correct value so we don't get all of this extra
output, which isn't useful to the user and is just going to alarm them
unnecessarily.

						- Ted

  reply	other threads:[~2012-01-31 20:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07  8:10 [BUG] e2fsprogs: e2fsck -b outputs checksum warnings Akira Fujita
2012-01-31 20:43 ` Eric Sandeen
2012-01-31 20:56   ` Ted Ts'o [this message]
2012-01-31 22:17     ` Andreas Dilger

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=20120131205657.GC25951@thunk.org \
    --to=tytso@mit.edu \
    --cc=a-fujita@rs.jp.nec.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    /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