From: Eric Sandeen <sandeen@redhat.com>
To: kreijack@inwind.it, linux-btrfs <linux-btrfs@vger.kernel.org>
Cc: jshubin@redhat.com
Subject: Re: PATCH V3] mkfs.btrfs: allow UUID specification at mkfs time
Date: Wed, 14 May 2014 17:07:04 -0500 [thread overview]
Message-ID: <5373E908.4040800@redhat.com> (raw)
In-Reply-To: <5373E864.4040807@libero.it>
On 5/14/14, 5:04 PM, Goffredo Baroncelli wrote:
> On 05/14/2014 07:39 PM, Eric Sandeen wrote:
>> Allow the specification of the filesystem UUID at mkfs time.
>>
>> Non-unique unique IDs are rejected. This includes attempting
>> to re-mkfs with the same UUID; if you really want to do that,
>> you can mkfs with a new UUID, then re-mkfs with the one you
>> wanted. ;)
>>
>> (Implemented only for mkfs.btrfs, not btrfs-convert).
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> NB: the prior patch didn't work well if you re-mkfs'd with
>> the same UUID; to be honest I didn't get to the bottom of it,
>> but the fact that that old UUID was already in an internal
>> list of present devices seems to have confused things.
>>
>> V2: reject non-unique unique IDs.
>> V3: test for non-unique unique IDs early in mkfs.
>>
<snip>
>> @@ -1368,6 +1374,20 @@ int main(int ac, char **av)
>> "The -r option is limited to a single device\n");
>> exit(1);
>> }
>> +
>> + if (fs_uuid) {
>> + uuid_t dummy_uuid;
>> +
>> + if (uuid_parse(fs_uuid, dummy_uuid) != 0) {
>> + fprintf(stderr, "could not parse UUID: %s\n", fs_uuid);
>> + exit(1);
>> + }
>> + if (!test_uuid_unique(fs_uuid)) {
>> + fprintf(stderr, "non-unique UUID: %s\n", fs_uuid);
>> + exit(1);
>> + }
>
> My test showed that this detect a false positive when the user tries to mkfs two time on the same device with the same uuid.
It's not a false positive; after the first mkfs, the UUID does exist. :) See also the commit log I wrote.
>> diff --git a/utils.c b/utils.c
>> index 3e9c527..cfac0d4 100644
>> --- a/utils.c
>> +++ b/utils.c
>> @@ -93,12 +93,41 @@ static u64 reference_root_table[] = {
>> [6] = BTRFS_CSUM_TREE_OBJECTID,
>> };
>>
>> -int make_btrfs(int fd, const char *device, const char *label,
>> +int test_uuid_unique(char *fs_uuid)
>> +{
>> + int unique = 1;
>> + blkid_dev_iterate iter = NULL;
>> + blkid_dev dev = NULL;
>> + blkid_cache cache = NULL;
>> +
>> + if (blkid_get_cache(&cache, 0) < 0) {
>> + printf("ERROR: lblkid cache get failed\n");
>> + return 1;
>> + }
>> + blkid_probe_all(cache);
>> + iter = blkid_dev_iterate_begin(cache);
>> + blkid_dev_set_search(iter, "UUID", fs_uuid);
>> +
>> + while (blkid_dev_next(iter, &dev) == 0) {
>
> This function should skip the check for the devices involved in the mkfs.
Perhaps. When I was doing something similar before, I ended up with
inexplicable segfaults when a device found on initial scan (?) got recreated
with the same UUID. Or something.
<snip>
>> @@ -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.
-Eric
next prev parent reply other threads:[~2014-05-14 22:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 1:18 [PATCH] mkfs.btrfs: allow UUID specification at mkfs time Eric Sandeen
2014-05-14 7:31 ` Wang Shilong
2014-05-14 12:25 ` Brendan Hide
2014-05-14 13:34 ` Duncan
2014-05-14 14:42 ` James Shubin
2014-05-14 13:28 ` Eric Sandeen
2014-05-14 13:34 ` David Pottage
2014-05-14 14:39 ` Goffredo Baroncelli
2014-05-14 14:41 ` Eric Sandeen
2014-05-14 15:14 ` Goffredo Baroncelli
2014-05-14 15:27 ` David Sterba
2014-05-14 14:47 ` James Shubin
2014-05-14 15:35 ` [PATCH V2] " Eric Sandeen
2014-05-14 16:01 ` David Sterba
2014-05-14 16:09 ` Eric Sandeen
2014-05-14 16:52 ` Goffredo Baroncelli
2014-05-14 17:39 ` PATCH V3] " Eric Sandeen
2014-05-14 22:04 ` Goffredo Baroncelli
2014-05-14 22:07 ` Eric Sandeen [this message]
2014-05-15 17:39 ` David Sterba
2014-05-15 17:53 ` Eric Sandeen
2014-05-16 17:24 ` David Sterba
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=5373E908.4040800@redhat.com \
--to=sandeen@redhat.com \
--cc=jshubin@redhat.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@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).