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..... [ I'm starting to think the mere mention of "UUID" causes people to lose 20 IQ points instantly. :P ] > 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). > 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... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
