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

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

[Mika Eloranta]

The UUID can now be optionally specified during filesystem
creation.
---
 man/man8/mkfs.xfs.8 |  7 +++++++
 mkfs/xfs_mkfs.c     | 12 ++++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/man/man8/mkfs.xfs.8 b/man/man8/mkfs.xfs.8
index 6260e0c..ab48dd7 100644
--- a/man/man8/mkfs.xfs.8
+++ b/man/man8/mkfs.xfs.8
@@ -38,6 +38,9 @@ mkfs.xfs \- construct an XFS filesystem
 .B \-L
 .I label
 ] [
+.B \-U
+.I uuid
+] [
 .B \-N
 ] [
 .B \-K
@@ -816,6 +819,10 @@ will not proceed with creating the filesystem.  Refer to the
 .BR mount "(8) and " xfs_admin (8)
 manual entries for additional information.
 .TP
+.BI \-U " uuid"
+Create the filesystem with the specified
+.IR UUID .
+.TP
 .B \-N
 Causes the file system parameters to be printed out without really
 creating the file system.
diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
index d993fc0..9fc5c67 100644
--- a/mkfs/xfs_mkfs.c
+++ b/mkfs/xfs_mkfs.c
@@ -948,6 +948,7 @@ main(
 	bool			finobtflag;
 	int			spinodes;
 
+	platform_uuid_clear(&uuid);
 	progname = basename(argv[0]);
 	setlocale(LC_ALL, "");
 	bindtextdomain(PACKAGE, LOCALEDIR);
@@ -990,7 +991,7 @@ main(
 	xi.isdirect = LIBXFS_DIRECT;
 	xi.isreadonly = LIBXFS_EXCLUSIVELY;
 
-	while ((c = getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) != EOF) {
+	while ((c = getopt(argc, argv, "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) != EOF) {
 		switch (c) {
 		case 'C':
 		case 'f':
@@ -1465,6 +1466,10 @@ main(
 				illegal(optarg, "L");
 			label = optarg;
 			break;
+		case 'U':
+			if (platform_uuid_parse(optarg, &uuid))
+				illegal(optarg, "U");
+			break;
 		case 'm':
 			p = optarg;
 			while (*p != '\0') {
@@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"),
 	sbp->sb_dblocks = dblocks;
 	sbp->sb_rblocks = rtblocks;
 	sbp->sb_rextents = rtextents;
-	platform_uuid_generate(&uuid);
+	if (platform_uuid_is_null(&uuid)) {
+	    platform_uuid_generate(&uuid);
+	}
 	platform_uuid_copy(&sbp->sb_uuid, &uuid);
 	/* Only in memory; libxfs expects this as if read from disk */
 	platform_uuid_copy(&sbp->sb_meta_uuid, &uuid);
@@ -3175,6 +3182,7 @@ usage( void )
 			    sunit=value|su=num,sectlog=n|sectsize=num,\n\
 			    lazy-count=0|1]\n\
 /* label */		[-L label (maximum 12 characters)]\n\
+/* uuid */		[-U uuid]\n\
 /* naming */		[-n log=n|size=num,version=2|ci,ftype=0|1]\n\
 /* no-op info only */	[-N]\n\
 /* prototype file */	[-p fname]\n\
-- 
2.3.5

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

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

[Dave Chinner]

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?

We need some explaination in the commit message so that when we look
at this in a couple of years time we know why we added this to
mkfs...

> @@ -948,6 +948,7 @@ main(
>  	bool			finobtflag;
>  	int			spinodes;
>  
> +	platform_uuid_clear(&uuid);
>  	progname = basename(argv[0]);
>  	setlocale(LC_ALL, "");
>  	bindtextdomain(PACKAGE, LOCALEDIR);
> @@ -990,7 +991,7 @@ main(
>  	xi.isdirect = LIBXFS_DIRECT;
>  	xi.isreadonly = LIBXFS_EXCLUSIVELY;
>  
> -	while ((c = getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) != EOF) {
> +	while ((c = getopt(argc, argv, "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) != EOF) {
>  		switch (c) {
>  		case 'C':
>  		case 'f':
> @@ -1465,6 +1466,10 @@ main(
>  				illegal(optarg, "L");
>  			label = optarg;
>  			break;
> +		case 'U':
> +			if (platform_uuid_parse(optarg, &uuid))
> +				illegal(optarg, "U");
> +			break;

I'd prefer not to introduce new top level options if possible - this
seems to fit under the -m (global metadata options) option subgroup
(i.e. -m uuid=<UUID>).

>  		case 'm':
>  			p = optarg;
>  			while (*p != '\0') {
> @@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"),
>  	sbp->sb_dblocks = dblocks;
>  	sbp->sb_rblocks = rtblocks;
>  	sbp->sb_rextents = rtextents;
> -	platform_uuid_generate(&uuid);
> +	if (platform_uuid_is_null(&uuid)) {
> +	    platform_uuid_generate(&uuid);
> +	}

Just generate the uuid initially and then it gets overwritten by the
CLI option if it is set. No need for null detection and generation
here.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

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

[Mika Eloranta]

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.
Use case: pre-defined UUID set for the filesystem by an _external system_ so that a detached (network) filesystem can later be correctly identified/verified by its UUID (i.e. by the contents of the filesystem instead of metadata outside the filesystem). For example, first creating a database record for a block filesystem with a random UUIDv4 and creating the actual filesystem with the same UUID only after that.
“mkfs.ext4" already supports this with the same exact invocation.

xfs_admin -U <uuid> does not seem to be an option because:

* xfs_admin -U option is going away? http://oss.sgi.com/pipermail/xfs/2015-April/041265.html
* Other people have issues with it: https://bugzilla.redhat.com/show_bug.cgi?id=1233220
* I get inconsistent behavior with it: about half of the time /dev/disk/by-uuid/* or “lsblk" do NOT see the change (Fedora 22).
* Pre-assigning the UUID straight away during the filesystem creation will work around any current or future bugs (e.g. above) and limitations regarding changing the UUID.
* When you need a filesystem with a specific UUID, it is an unnecessary extra step to first create it with a random UUID and only afterwards set it to the one you need.

> We need some explaination in the commit message so that when we look
> at this in a couple of years time we know why we added this to
> mkfs…

Sure, I can update the commit message.

Please let me know if you need more clarifications, thanks!

Cheers,

	- Mika

> 
>> @@ -948,6 +948,7 @@ main(
>> 	bool			finobtflag;
>> 	int			spinodes;
>> 
>> +	platform_uuid_clear(&uuid);
>> 	progname = basename(argv[0]);
>> 	setlocale(LC_ALL, "");
>> 	bindtextdomain(PACKAGE, LOCALEDIR);
>> @@ -990,7 +991,7 @@ main(
>> 	xi.isdirect = LIBXFS_DIRECT;
>> 	xi.isreadonly = LIBXFS_EXCLUSIVELY;
>> 
>> -	while ((c = getopt(argc, argv, "b:d:i:l:L:m:n:KNp:qr:s:CfV")) != EOF) {
>> +	while ((c = getopt(argc, argv, "b:d:i:l:L:U:m:n:KNp:qr:s:CfV")) != EOF) {
>> 		switch (c) {
>> 		case 'C':
>> 		case 'f':
>> @@ -1465,6 +1466,10 @@ main(
>> 				illegal(optarg, "L");
>> 			label = optarg;
>> 			break;
>> +		case 'U':
>> +			if (platform_uuid_parse(optarg, &uuid))
>> +				illegal(optarg, "U");
>> +			break;
> 
> I'd prefer not to introduce new top level options if possible - this
> seems to fit under the -m (global metadata options) option subgroup
> (i.e. -m uuid=<UUID>).
> 
>> 		case 'm':
>> 			p = optarg;
>> 			while (*p != '\0') {
>> @@ -2550,7 +2555,9 @@ _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"),
>> 	sbp->sb_dblocks = dblocks;
>> 	sbp->sb_rblocks = rtblocks;
>> 	sbp->sb_rextents = rtextents;
>> -	platform_uuid_generate(&uuid);
>> +	if (platform_uuid_is_null(&uuid)) {
>> +	    platform_uuid_generate(&uuid);
>> +	}
> 
> Just generate the uuid initially and then it gets overwritten by the
> CLI option if it is set. No need for null detection and generation
> here.
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com

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

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

[Dave Chinner]

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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

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

[Eric Sandeen]

On 9/21/15 5:18 PM, Dave Chinner 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?

At mkfs time it should be the same / both.  (the only reason they need
to diverge is a post-mkfs user-visible change on a V5 fs).

 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?
> 
> We need some explaination in the commit message so that when we look
> at this in a couple of years time we know why we added this to
> mkfs...

I'm a little curious to know why it's desired, but it's also so trivial
it seems worth accepting if it's useful to someone.

mke2fs (mkfs.ext[234]) and mkfs.btrfs can do this today as well, so
something seems to be driving the desire for the feature.

-Eric

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

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

[Mika Eloranta]

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.

Cheers,

    Mika

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

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

[Carlos Maiolino]

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

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

[Dave Chinner]

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.

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@fromorbit.com

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

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

[Mika Eloranta]

> On 22 Sep 2015, at 10:52, Dave Chinner <david@fromorbit.com> wrote:
> 
> 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.
> 
> 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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Tue, Sep 22, 2015 at 11:06:35AM +0300, Mika Eloranta wrote:
> > On 22 Sep 2015, at 10:52, Dave Chinner <david@fromorbit.com> wrote:
> > 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.

The usual problem - we're all subject matter experts in
our own domains, and what is obvious to us isn't obvious to
someone in a slightly different domain, even though they interact at
some level.

> Regarding updating the patch: “-U uuid” (mkfs.ext*/mkfs.btrfs -style) or
> "-m uuid=<uuid>” as per proposal by Carlos?

-m uuid=<uuid>, please.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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