Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     NeilBrown <neilb@suse.de>
Cc:     "Trond Myklebust" <trondmy@hammerspace.com>, steved@redhat.com,
        linux-nfs@vger.kernel.org
Subject: Re: [nfs-utils PATCH] nfs4id: a tool to create and persist nfs4
 client uniquifiers
Date:   Fri, 11 Feb 2022 08:35:22 -0500
Message-ID: <299337F3-E83F-49EC-BB24-C9B859C9FB6D@redhat.com>
In-Reply-To: <164453369792.27779.10668875903268728405@noble.neil.brown.name>
References: <c2e8b7c06352d3cad3454de096024fff80e638af.1643979161.git.bcodding@redhat.com>
 <6f01c382-8da5-5673-30db-0c0099d820b5@redhat.com>
 <0AB20C82-6200-46E0-A76C-62345DAF8A3A@redhat.com>
 <6cfb516d-0747-a749-b310-1368a2186307@redhat.com>
 <164444169523.27779.10904328736784652852@noble.neil.brown.name>
 <39e7bba4243eb2f16d99fefb43fef6b3ff741f87.camel@hammerspace.com>
 <164445109064.27779.13269022853115063257@noble.neil.brown.name>
 <6BAAA0D0-7212-480F-9C33-DA1F656FF09F@redhat.com>
 <164453369792.27779.10668875903268728405@noble.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 10 Feb 2022, at 17:54, NeilBrown wrote:

> On Thu, 10 Feb 2022, Benjamin Coddington wrote:
>>
>> Yes, but even better than having the tool do the writing is to have 
>> udev do
>> it, because udev makes the problem of when and who will execute this 
>> tool go
>> away, and the entire process is configurable for anyone that needs to 
>> change
>> any part of it or use their own methods of generating/storing ids.
>
> I really don't understand the focus on udev.
>
> Something, somewhere, deliberately creates the new network namespace.
> It then deliberately configures that namespace - creating a virtual
> device maybe, adding an IP address, setting a default route or 
> whatever.
> None of that is done by udev rules (is it)?
> Setting the NFS identity is just another part of configuring the new
> network namespace.
>
> udev is great when we don't know exactly when an event will happen, 
> but
> we want to respond when it does.
> That doesn't match the case of creating a new network namespace.  Some
> code deliberately creates it and is perfectly positioned to then
> configure it.

I think there's so many ways to create a new network namespace that we 
can't
reasonably be expected to try to insert out problem into all of them.
Handling the event from the kernel allows us to make a best-effort 
default
attempt.

> udev is async.  How certain can we be that the udev event will be 
> fully
> handled before the first mount attempt?

Good point.  We can't at all be certain.

We can start over completely from here..

We can have mount.nfs /also/ try to configure the id.. this is more 
robust.

We can have mount.nfs do a round of udev settle..

Are there other options?

Ben