linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Joseph D. Wagner" <joe@josephdwagner.info>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Metadata Checksums Include fs_uuid?
Date: Tue, 17 Jun 2014 12:47:48 -0400	[thread overview]
Message-ID: <20140617164748.GA24890@thunk.org> (raw)
In-Reply-To: <e54129c593d975dcd28431a2c9b29438@josephdwagner.info>

On Tue, Jun 17, 2014 at 09:38:35AM -0700, Joseph D. Wagner wrote:
> It appears to describe the file system UUID as part of the checksum.  Is
> that correct?

Yes, it is correct.

> I am a little concerned, because the UUID can be changed manually using
> tune2fs.  Does changing the UUID invalidate the checksums?  Does tune2fs
> update the checksums based upon the new UUID?

Tune2fs updates the checksums based on the new UUID, yes.

> Why does the file system UUID even need to be part of the checksum?

This allows us to detect metadata blocks (in particular, portions of
the inode table which haven't been cleared yet) from previous file
systems.

There is a question of what to e2fsck should do when a metadata
checksum is invalid.  We do need to make e2fsck smarter so it does the
right thing automatically.  So for example, if the block group
descriptor checksums are invalid, so we read the backup block group
descriptors, we know that the last inode initialized fields are not
accurate.  In that case, if an inode table block has an invalid
checksum, we could ignore those blocks automatically without bothering
the user about it.  If we did all of this, then we could skip the lazy
inode table initialization when metadata_csum is enabled, since that
tends to impact performance for the a few hours when the file system
is first mounted.

Cheers,

						- Ted

      reply	other threads:[~2014-06-17 16:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 16:38 Metadata Checksums Include fs_uuid? Joseph D. Wagner
2014-06-17 16:47 ` Theodore Ts'o [this message]

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=20140617164748.GA24890@thunk.org \
    --to=tytso@mit.edu \
    --cc=joe@josephdwagner.info \
    --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).