[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160416154538.GC5447@thunk.org>
Date: Sat, 16 Apr 2016 11:45:38 -0400
From: Theodore Ts'o <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 3/4] e2fsck: don't try to set a UUID on metadata_csum
file systems
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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists