> 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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
