From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 3/4] e2fsck: don't try to set a UUID on metadata_csum file systems
Date: Sat, 16 Apr 2016 11:45:38 -0400 [thread overview]
Message-ID: <20160416154538.GC5447@thunk.org> (raw)
In-Reply-To: <062EB0E7-1B5E-4DF0-B4B2-F87A7566A81F@dilger.ca>
On Fri, Apr 15, 2016 at 09:06:04PM -0600, Andreas Dilger wrote:
> > If the UUID field is NULL, e2fsck will try to generate and set a new
> > UUID. This will cause massive problems if the metadata_csum feature
> > is set, so avoid doing so in that case.
>
> Should enabling the metadata csum feature complain/fail if the checksum
> is unset? It doesn't make sense to use a NULL UUID as the checksum salt.
Well, for hard disks, it's certainly not a great idea, although it
won't automatically break things. For images that are being cloned
for VM's, the UUID's are all going to be the same anyway, so whether
they are all NULL or all "964ef7ca-ddce-4ce2-906e-d2d69be29b1f"
doesn't really matter a whole lot. And the same holds true if someone
recreates a file system on a HDD with an explicitly specified UUID
which is the same as what had previously been used on that file
system.
The real problem was the mistake we made in overloading the UUID is
the checksum seed. We've fixed that, but it's going to be quite a
while before we can assume that it is generally available.
I could see adding a warning message to mke2fs if the user specifies a
UUID (whether it be NULL or any other value) but I'm not really sure
it's worth it.
Cheers,
- Ted
next prev parent reply other threads:[~2016-04-16 15:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-16 1:13 [PATCH 1/4] Fix support for configure --enable-jbd-debug Theodore Ts'o
2016-04-16 1:13 ` [PATCH 2/4] e2fsck: use specific CRC and corruption errors in journal recovery Theodore Ts'o
2016-04-16 1:13 ` [PATCH 3/4] e2fsck: don't try to set a UUID on metadata_csum file systems Theodore Ts'o
2016-04-16 3:06 ` Andreas Dilger
2016-04-16 15:45 ` Theodore Ts'o [this message]
2016-04-16 1:13 ` [PATCH 4/4] e2fsck: don't abort if the journal is corrupted due to checksum errors Theodore Ts'o
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=20160416154538.GC5447@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.