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:     trond.myklebust@hammerspace.com, anna.schumaker@netapp.com
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFSv4: Tune the race to set and use the client id
 uniquifier
Date:   Mon, 28 Feb 2022 11:07:10 -0500
Message-ID: <0F8CD466-6233-4386-94C5-FC8E5941F9D3@redhat.com>
In-Reply-To: <3EA14A5C-9FF9-4DDC-B530-768A86E2A4E8@redhat.com>
References: <61a5993a1f9bbed2ba1227bd3376e92232e0530a.1645033262.git.bcodding@redhat.com>
 <3EA14A5C-9FF9-4DDC-B530-768A86E2A4E8@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Precedence: bulk

On 17 Feb 2022, at 7:48, Benjamin Coddington wrote:

> Trond and Anna, this patch makes obvious one problem with the udev 
> approach.
> We cannot depend fully on stable uniquifiers.  The conversation on the
> userspace side has come full circle to asserting we use a mount 
> option.
>
> Do you still want us to keep this approach, or will you accept a mount
> option as:
>  - first mount in a namespace sets the identifier
>  - subsequent mounts with conflicting identifiers return an error
>
> If we keep this udev approach, this patch isn't necessary but does 
> greatly
> reduce the chances of having clients with unstable identifiers.
>
> No one can be blamed for ignoring this, but it would be a relief to 
> get this
> problem solved so it can stop burning our time.
>
> Please advise,
> Ben

Attempts to work toward solutions in this area seem to be ignored, the
questions still stand.  Until we can sort out and agree on a direction,
self-NACK to this patch.

Ben