Re: [PATCH] mkfs.xfs: add [-U uuid] option

[Carlos Maiolino <cmaiolino@redhat.com>]

On Tue, Sep 22, 2015 at 09:43:34AM +0300, Mika Eloranta wrote:
> On 22 Sep 2015, at 02:36, Dave Chinner <david@fromorbit.com> wrote:
> > 
> > On Tue, Sep 22, 2015 at 01:56:53AM +0300, Mika Eloranta wrote:
> >> On 22 Sep 2015, at 01:18, Dave Chinner <david@fromorbit.com>
> >> 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.
> 

Hi Mika,

I don't think that Dave's argument was regarding technical reasons, but the lack
of information about the feature. Use case, etc

We already have too many options in the xfs tools, and also, a way to set the
uuid to a filesystem as explained before, and, although it is not harmful as you
said, and I should say I agree with you in this point, the fact that you sent
the patch without detailed information about why it is useful and the use cases
for that (that you just described here), makes people ask you all these
questions, mainly when there were no previous discussion regarding the feature,
so, just keep in mind that in the next patches you might send, add as much
information as possible, to (maybe :) speed up the integration of the patch, and
even though, you're not free to have people asking you lots of questions
regarding your patch.


But anyway, I agree with the patchset and the points are fair enough for having
this option, but having it as a -m uuid=<uuid> instead of -U <uuid> makes more
sense here.

> Cheers,
> 
>     Mika
> 

-- 
Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs