* [PATCH] mkfs.xfs: add [-U uuid] option @ 2015-09-21 17:04 Mika Eloranta 2015-09-21 22:18 ` Dave Chinner 0 siblings, 1 reply; 10+ messages in thread From: Mika Eloranta @ 2015-09-21 17:04 UTC (permalink / raw) To: xfs; +Cc: 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-21 17:04 [PATCH] mkfs.xfs: add [-U uuid] option Mika Eloranta @ 2015-09-21 22:18 ` Dave Chinner 2015-09-21 22:56 ` Mika Eloranta 2015-09-22 1:42 ` Eric Sandeen 0 siblings, 2 replies; 10+ messages in thread From: Dave Chinner @ 2015-09-21 22:18 UTC (permalink / raw) To: Mika Eloranta; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-21 22:18 ` Dave Chinner @ 2015-09-21 22:56 ` Mika Eloranta 2015-09-21 23:36 ` Dave Chinner 2015-09-22 1:42 ` Eric Sandeen 1 sibling, 1 reply; 10+ messages in thread From: Mika Eloranta @ 2015-09-21 22:56 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-21 22:56 ` Mika Eloranta @ 2015-09-21 23:36 ` Dave Chinner 2015-09-22 6:43 ` Mika Eloranta 0 siblings, 1 reply; 10+ messages in thread From: Dave Chinner @ 2015-09-21 23:36 UTC (permalink / raw) To: Mika Eloranta; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-21 23:36 ` Dave Chinner @ 2015-09-22 6:43 ` Mika Eloranta 2015-09-22 7:22 ` Carlos Maiolino 2015-09-22 7:52 ` Dave Chinner 0 siblings, 2 replies; 10+ messages in thread From: Mika Eloranta @ 2015-09-22 6:43 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-22 6:43 ` Mika Eloranta @ 2015-09-22 7:22 ` Carlos Maiolino 2015-09-22 7:52 ` Dave Chinner 1 sibling, 0 replies; 10+ messages in thread From: Carlos Maiolino @ 2015-09-22 7:22 UTC (permalink / raw) To: Mika Eloranta; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-22 6:43 ` Mika Eloranta 2015-09-22 7:22 ` Carlos Maiolino @ 2015-09-22 7:52 ` Dave Chinner 2015-09-22 8:06 ` Mika Eloranta 1 sibling, 1 reply; 10+ messages in thread From: Dave Chinner @ 2015-09-22 7:52 UTC (permalink / raw) To: Mika Eloranta; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-22 7:52 ` Dave Chinner @ 2015-09-22 8:06 ` Mika Eloranta 2015-09-22 8:25 ` Dave Chinner 0 siblings, 1 reply; 10+ messages in thread From: Mika Eloranta @ 2015-09-22 8:06 UTC (permalink / raw) To: Dave Chinner; +Cc: xfs > 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-22 8:06 ` Mika Eloranta @ 2015-09-22 8:25 ` Dave Chinner 0 siblings, 0 replies; 10+ messages in thread From: Dave Chinner @ 2015-09-22 8:25 UTC (permalink / raw) To: Mika Eloranta; +Cc: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mkfs.xfs: add [-U uuid] option 2015-09-21 22:18 ` Dave Chinner 2015-09-21 22:56 ` Mika Eloranta @ 2015-09-22 1:42 ` Eric Sandeen 1 sibling, 0 replies; 10+ messages in thread From: Eric Sandeen @ 2015-09-22 1:42 UTC (permalink / raw) To: xfs 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-09-22 8:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-09-21 17:04 [PATCH] mkfs.xfs: add [-U uuid] option Mika Eloranta 2015-09-21 22:18 ` Dave Chinner 2015-09-21 22:56 ` Mika Eloranta 2015-09-21 23:36 ` Dave Chinner 2015-09-22 6:43 ` Mika Eloranta 2015-09-22 7:22 ` Carlos Maiolino 2015-09-22 7:52 ` Dave Chinner 2015-09-22 8:06 ` Mika Eloranta 2015-09-22 8:25 ` Dave Chinner 2015-09-22 1:42 ` Eric Sandeen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox