linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: linux-ext4@vger.kernel.org
Subject: simple block bitmap sanity checking
Date: Fri, 6 Jul 2007 12:48:56 -0600	[thread overview]
Message-ID: <20070706184856.GA13812@schatzie.adilger.int> (raw)

During a discussion at OLS, I came up with a very simple way of validating
the ext2/3/4 block bitmaps at read time.  Until such a time when we have
checksums for the bitmaps we can have a simple but quite robust mechanism
that is useful for ext2/3/4.

When a new block bitmap is read from disk in read_block_bitmap() there are a
few bits that should ALWAYS be set.  In particular, the blocks given by
desc->bg_block_bitmap, desc->bg_inode_bitmap, and the inode table in
[desc->bg_inode_table, +sbi->s_itb_per_group].  If those bits (shifted to be
relative to the current group, of course) are not set then the on-disk group
descriptor is corrupt, or there is some problem reading it from disk, and
this needs to generate an extN_error() call[*] to make the fs read-only.

A similar check can be done with the inode bitmap - it should have the
bits at the end of each bitmap set, for bits higher than s_inodes_per_group.

What I'm wondering is if anyone has time to implement this idea?  I'm
estimating it wouldn't be about 30 lines of simple code in total.

[*] This reminds me - we should make the default ext4 error behaviour be
    the safer "remount-ro" instead of the dangerous "continue".

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

             reply	other threads:[~2007-07-06 18:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-06 18:48 Andreas Dilger [this message]
2007-07-09 17:22 ` simple block bitmap sanity checking Aneesh Kumar K.V
2007-07-09 18:58   ` 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=20070706184856.GA13812@schatzie.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    /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).