On 5/15/14, 12:39 PM, David Sterba wrote: > On Wed, May 14, 2014 at 05:07:04PM -0500, Eric Sandeen wrote: >>>> @@ -125,7 +154,20 @@ int make_btrfs(int fd, const char *device, const char >>>> *label, >>>> memset(&super, 0, sizeof(super)); >>>> >>>> num_bytes = (num_bytes / sectorsize) * sectorsize; >>>> - uuid_generate(super.fsid); >>>> + if (fs_uuid) { >>>> + if (uuid_parse(fs_uuid, super.fsid) != 0) { >>>> + fprintf(stderr, "could not parse UUID: %s\n", fs_uuid); >>>> + ret = -EINVAL; >>>> + goto out; >>>> + } >>>> + if (!test_uuid_unique(fs_uuid)) { >>>> + fprintf(stderr, "non-unique UUID: %s\n", fs_uuid); >>>> + ret = -EBUSY; >>>> + goto out; >>>> + } >>> >>> Why a second call to test_uuid_unique(fs_uuid) ? >> >> Because kdave said he thought it was worth being paranoid in an earlier >> email, >> if I understood him correctly. > > I'm thinking about it again. My original idea was not to easily allow > to create a duplicate uuid to a regular user. But, if one uses --uuid > already, that's something I can count as a willful action and any > mistakes can be blamed on the user. > > If we end up with a warning, then the documentation should say how > spectacularly it can blow up the system. >
So, in my testing, I found that re-mkfsing a device with the same UUID lead to weird & distant segfaults in other bits of code. Probably due to the uuid cache? </handwave> - I didn't dig into it, because ... ... people didn't want to be able to create duplicate UUIDs, so I figured the outright rejection of that was a trivial way to solve it ... And like I mentioned, if you really want to recreate the same UUID, you can mkfs twice. It doesn't take long. ;) I dunno, maybe that's too lame. For a feature that upstream development doesn't really seem to want, I'm not sure how much more effort I should put into it? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html