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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
