On 14 Feb 2022, at 10:39, Chuck Lever III wrote:
On Feb 14, 2022, at 6:15 AM, Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
On 13 Feb 2022, at 19:04, NeilBrown wrote:
On Sat, 12 Feb 2022, Benjamin Coddington wrote:
On 11 Feb 2022, at 15:51, Chuck Lever III wrote:
On Feb 11, 2022, at 3:16 PM, Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
On 11 Feb 2022, at 15:00, Chuck Lever III wrote:
On Feb 11, 2022, at 2:30 PM, Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
All the arguments for exacting tolerances on how it should be
named
apply
equally well to anything that implies its output will be used
for
nfs client
ids, or host ids.
I completely disagree with this assessment.
But how, and in what way? The tool just generates uuids, and
spits
them
out, or it spits out whatever's in the file you specify, up to 64
chars. If
we can't have uuid in the name, how can we have NFS or machine-id
or
host-id?
We don't have a tool called "string" to get and set the DNS name
of
the local host. It's called "hostname".
The purpose of the proposed tool is to persist a unique string to
be
used as part of an NFS client ID. I would like to name the tool
based
on that purpose, not based on the way the content of the
persistent
file happens to be arranged some of the time.
When the tool generates the string, it just happens to be a UUID.
It
doesn't have to be. The tool could generate a digest of the boot
time
or the current time. In fact, one of those is usually part of
certain
types of a UUID anyway. The fact that it is a UUID is totally not
relevant. We happen to use a UUID because it has certain global
uniqueness properties. (By the way, perhaps the man page could
mention
that global uniqueness is important for this identifier. Anything
with
similar guaranteed global uniqueness could be used).
You keep admitting that the tool can output something that isn't a
UUID. Doesn't that make my argument for me: that the tool doesn't
generate a UUID, it manages a persistent host identifier. Just
like
"hostname." Therefore "nfshostid". I really don't see how
nfshostid
is just as miserable as nfsuuid -- hence, I completely disagree
that "all arguments ... apply equally well".
Yes - your arguement is a good one. I wasn't clear enough
admitting
you
were right two emails ago, sorry about that.
However, I still feel the same argument applied to "nfshostid"
disqualifies
it as well. It doesn't output the nfshostid. That, if it even
contains
the
part outputted, is more than what's written out.
In my experience with linux tools, nfshostid sounds like something
I can
use
to set or retrieve the identifier for an NFS host, and this little
tool
does
not do that.
I agree. This tool primarily does 1 thing - it sets a string which
will
be the uniquifier using the the client_owner4. So I think the word
"set" should appear in the name. I also think the name should start
"nfs".
I don't much care whether it is
nfssetid
nfs-set-uuid
nfssetowner
nfssetuniquifier
nfssetidentity
nfsidset
though perhaps I'd prefer
nfs=set=id
If not given any args, it should probably print a usage message
rather
than perform a default action, to reduce the number of holes in
feet.
.... Naming - THE hard problem of computer engineering ....
No, it does NOT set the uniquifier string. It returns it on stdout.
If
you run it without args it just prints the string. Its completely
harmless.
OK, my understanding was that if you run it as root, and the
string isn't already set, it does indeed set a value in the
persistence file.
That should be harmless, though. Once it is set, it is always
the same afterwards, and that's fine. Someone who just types
in the command to see what it does can't damage their
metatarsals; the worst that happens is the persistence file
is never used again.
I agree that's not very "set"-like.
nfsgetuniquifier
nfsguestuniquifier
nfsnsuniquifier
ns-uniquifier
Use with copious amounts of tab completion.
Coming back to this.. so it seems at least part of our disagreement
about
the name had to do with a misunderstanding of what the tool did.
Just to finally clear the air about it: the tool does not write to
sysfs, it
doesn't try to modify the client in any way. I'm going to leave it up
to
the distros.
Considering this, I think your only remaining objection to "nfsuuid" is
that it
might return data other than a uuid if someone points it at a file that
contains data other than a uuid.
I can fix that. And its probably not a bad idea either. The nfsuuid
tool
can ensure that the persisted data is a uuid.
Maybe I also need to change the man page or description of the patch to
be
clearer about what the tool does. Any suggestions there?
Ben
