On 22 Sep 2015, at 02:36, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote:
>> On 22 Sep 2015, at 01:18, Dave Chinner <david@xxxxxxxxxxxxx>
>> wrote:
>>>
>>> On Mon, Sep 21, 2015 at 08:04:20PM +0300, Mika Eloranta wrote:
>>>> The UUID can now be optionally specified during filesystem
>>>> creation.
>>>
>>> Which UUID are you wanting to set - the metadata uuid or the
>>> user visible UUID label? Or both? Can you explain the use case
>>> for this? i.e. I'm trying to work out why Why doesn't mkfs.xfs
>>> + xfs_admin -U <uuid> doesn't work for you?
>>
>> I want to set the user visible UUID (same as xfs_admin -U/-u).
>> Whether this impacts the "metadata uuidâ or not, I do not
>> know, Iâm not an expert on the XFS internals, just a user.
>
> Which tells me what I need to know - You are trying to use the UUID
> as a user controlled filesystem label. Funnily enough, we have a
> thing for this already - a user controlled filesystem label:
>
> # mkfs.xfs -L "label" ....
>
> It's 12 characters long, so more than enough for any sort of unique
> identification scheme you want to use for your filesystems.
> xfs_admin enables you to change it after the fact, all major
> filesystems support it and all the infrastructure know about it
> (lsblk, /etc/fstab. /dev/disk/by-label, etc) so using it is no
> different to using UUIDs. Except that, unlike UUIDs, you can make
> fileystem labels human readable. :)
>
> Perhaps you should try using filesystem labels seeing as everything
> you need is already there?
Labels are great for user-readable identifiers, but UUID is nowadays
pretty much the norm for random-generated identifiers. My use-case
concerns distributed and automated virtual systems, where filesystems
are constantly built and torn down.
Using the filesystem label to store a truncated version of a UUID is
kind of an option, but I'd really rather use the entire UUID because:
1) Identifying an orphan filesystem based on its contents becomes
more straightforward, e.g. if they are already listed in a key-value
store based on their full UUID and prefix lookups are not possible.
2) The label is actually rather short for storing a random ID. For
example storing 48 bits from the UUID in the label hex-encoded
would give me a collision already in 20 million fs instances with
>50% probability.
I thought adding the option would be a rather straightforward thing,
especially when more problematic "xfs_admin -U" is (was?) already
supported. Is there technical reason why assigning the UUID is no longer
recommended? The patch only allows optionally using a user-specified
UUID instead of a one generated randomly on the spot within mkfs.xfs,
and I cannot see any harm in that.
Cheers,
Mika
|