Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Nikolay Borisov <nborisov@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: drop unique uuid test for btrfstune -M
Date: Tue, 10 Sep 2019 13:12:43 +0800	[thread overview]
Message-ID: <41b5b682-e67f-40d6-93cb-75e4889a4b06@oracle.com> (raw)
In-Reply-To: <673ba386-debc-96e9-311e-4c3c0abd89d0@suse.com>


Nikolay,

>>> This is intended. Otherwise it's an open avenue for the user to shoot
>>> themselves in the foot.
>>
>>   I don't understand how?

  Again. Any idea how? Is there any test case?

  <snip>

> UUID, by definition, are Unique. What you want to is
> to toss the Unique part, meaning we'll really be left with some sort of
> ID. What's more - the UUID is used by libblkid to populate the available
> devices so not making it unique can cause subtle bugs.

- Irrespective of the fstype, when fs image file is copied/snapshot-ed
   the fsid is indeed going to be duplicate.

- xfs and btrfs kernel doesn't allow duplicate fsid to be mounted which
   is fair and accepted. (I remember fixing the duplicate fsid bugs in
   the kernel, just fyi if you are concerned about them).

- ext4 kernel does allow duplicate fsid to be mounted.

- btrfstume -M <uuid> isn't the place to check if the fsid is a
   duplicate. Because, libblkid will be unaware of the complete list of
   fs images with its fsid.

- As I said before, its a genuine use-case here where the user wants to
   revert the fsid change, so that btrfs fs root image can be booted.
   Its up-to the user if fsid is duplicate in the user space, as btrfs
   kernel rightly fails the mount if its duplicate fsid anyways.

Thanks, Anand

  reply	other threads:[~2019-09-10  5:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-06  0:50 [PATCH] btrfs-progs: drop unique uuid test for btrfstune -M Anand Jain
2019-09-06  7:21 ` Nikolay Borisov
2019-09-06  9:27   ` Anand Jain
2019-09-09 11:40     ` Nikolay Borisov
2019-09-10  5:12       ` Anand Jain [this message]
2019-09-11 17:01         ` David Sterba
2019-09-12  0:45           ` Anand Jain
2019-09-24 11:20             ` Anand Jain
2019-10-01  8:08               ` Anand Jain
2019-10-17 16:32             ` David Sterba
2019-10-18  8:52               ` Anand Jain
2020-05-20 10:44                 ` Anand Jain

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=41b5b682-e67f-40d6-93cb-75e4889a4b06@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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