> On 22 Sep 2015, at 10:52, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> On Tue, Sep 22, 2015 at 09:43:34AM +0300, Mika Eloranta wrote:
>> 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.
>
> Sure. Your use case boils down to "we need to replace a randomly
> generated mkfs UUID with our own randomly generated UUID". Why not
> just read the randomly generated UUID out of the filesystem and put
> that in the database?
>
> There are many ways ot skin a cat, and I'm trying to understand why
> you need to skin it in this particular way... :/
>
>> 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.
>
> A label stores characters, not hex-encoded values. 12 characters,
> assuming A-Z, a-z, 0-9 is 62^12 possible combinations that can be
> stored. Indeed, Just 6 characters (half the label) gives you 56
> *billion* unique labels. But that's not obvious until you stop
> thinking about using UUIDs for everythingâ..
You are absolutely correct. However, when I have a UUID in my hand and
there is a slot called âUUID" and it is user-settable and it fits my ID
perfectly,
to me it is rather natural to use it instead of trying to invent new encoding
schemes for storing a part of it.
> [ I'm starting to think the mere mention of "UUID" causes people to
> lose 20 IQ points instantly. :P ]
No comments about this one.
>> I thought adding the option would be a rather straightforward thing,
>> especially when more problematic "xfs_admin -U" is (was?) already
>> supported.
>
> Bugs are a reality we have to live with. We've fixed them (I think).
And I thank you guys for that. Never had a showstopper with XFS. Unlike
with some other, krmh, unnamed options...
>> Is there technical reason why assigning the UUID is no longer
>> recommended?
>
> The changing of the XFS UUID was added for a very specific use case
> - allowing writable clones of a filesystem to be mounted so the
> "nouuid" mount option was unnecessary. You're the first person n
> 10 years to ask for something new in UUID handling and that is why
> I'm asking lots of questions....
>
>> 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.
>
> Sure, there may be no harm, but I'm starting from the position of
> knowing nothing about why you want the feature or how it will be
> used so I can't make that judgement just by looking at the code.
>
> Think on that for a moment - do you just include random code changes
> in your code base that you really know nothing about? Or do you ask
> questions and try to understand why it is needed first? Indeed,
> would you trust software maintained by someone who doesn't care to
> make informed decisions about the code base they are responsible
> for maintaining?
>
> Don't get me wrong here - I will take an updated patch from you for
> this functionality. Both you and Eric have very good points as to
> why mkfs should allow this, but I need to make sure /I/ understand
> the bigger picture before committing itâ
Lesson learned. Coming from my problem domain the feature seemed
obvious, but I can see the need for being more verbose about the âwhy?â
part. I did not realize this feature is not so commonly used.
Regarding updating the patch: â-U uuidâ (mkfs.ext*/mkfs.btrfs -style) or
"-m uuid=<uuid>â as per proposal by Carlos?
Iâll also try to summarize a better commit message.
Cheers,
- Mika
|