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:   Chuck Lever III <chuck.lever@oracle.com>
To:     Neil Brown <neilb@suse.de>
CC:     Benjamin Coddington <bcodding@redhat.com>,
        Steve Dickson <SteveD@RedHat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Trond Myklebust <trondmy@hammerspace.com>
Subject: Re: [PATCH v2] nfs.man: document requirements for NFSv4 identity
Thread-Topic: [PATCH v2] nfs.man: document requirements for NFSv4 identity
Thread-Index: AQHYNz9tXzp0vUT6Z02tg1tG8znMeKy/CFqAgACT9wCADEQzgA==
Date:   Tue, 22 Mar 2022 20:00:41 +0000
Message-ID: <9A76C91C-6C55-4090-A931-2E5C9D90FBEC@oracle.com>
References: <164721984672.11933.15475930163427511814@noble.neil.brown.name>
 <ED6618CE-EC09-448D-904C-F34FCE8E8935@oracle.com>
 <164730488811.11933.18315180827167871419@noble.neil.brown.name>
In-Reply-To: <164730488811.11933.18315180827167871419@noble.neil.brown.name>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GrMF8dDsvcL6BTtvJ/uo1xt2zWpKEbAQplKs4cHRuIm6PqJUsZ1EfsMclpla?=
 =?us-ascii?Q?cNn6+XBUBk3/JL9nFzZQaHxWZpOWfAWK+z9mzMlAsoJTF7nhmrMLgCSY7ZGe?=
 =?us-ascii?Q?YKfsj1sMybQ26trWu0piVX5Ba7ahD1MlrbjVhmGAFj5rhE2bIDpMB9QehcDj?=
 =?us-ascii?Q?HHUZj98aB7L5/mi6rU96q25SnmVxMVplHWwdGc9YGUvEVU7txi0LQDJFv6go?=
 =?us-ascii?Q?pfMTm7Rp9kMCCuRt2S4W8a9LtOmocDmNVFbps8k32k/C2oA0HjPheb5ojioX?=
 =?us-ascii?Q?VndzXOcu7+xGiMx06geCrCD+rt4R4b8b3gg9RwPqEYMI6Yh5fr5bL2VEbYCO?=
 =?us-ascii?Q?1Nd6G9GT45nGgufPYkMOYnFSHUd1KxCvEwHQ+f3InOarWbg/FR/moWwRLsHo?=
 =?us-ascii?Q?9GUsFl+A5PsX2oH4TX3/puJztwV7+z5peNsMa2uOKxZWBH9OkVwkcED8qfmc?=
 =?us-ascii?Q?7wh1WwErhGFd6JJOOlroGe9sWHSxbIkRol0YHkCja2OGi7cvKBU/YWqU6w5G?=
 =?us-ascii?Q?obA+R92V9tn/cgc1jNcKGyYlK21Ora/lt1X5pOKr54uXNKiglBtaznLpLVcZ?=
 =?us-ascii?Q?+vdflj128rvw2ASHFtz+3krgQb9tUizDOsYR2c2W+3qBnMYXKWfjki3YGeW2?=
 =?us-ascii?Q?s6cYCuBieF5tK7GViMJpryVtDe8jwOK0U9mCTWhX55dl/MCbA9GP64XHMQ8t?=
 =?us-ascii?Q?D81J+v+al6NlmazjKDY1i65QHrJndDaBQ/bbnnM+o84KyDNcKTAWto/rFJwN?=
 =?us-ascii?Q?Kq2hjCSZg5xsfgZLmlQyQVB2V7ZjwmwV3NxVUkilx/UHq7Y/UyeTxinDN23f?=
 =?us-ascii?Q?Oz2mdVQnvkGytZHOSYa+zIVRaqvxqe9nVRDKrzOFoL3kabt6IVRBt6gS43Zo?=
 =?us-ascii?Q?HPtr+hKf1fDV8kJEe4tOQC4Mr91+yg8F1hQ671MnQVN6G0dLB7RjO3QzpAr2?=
 =?us-ascii?Q?C1tof+yYI/oJpUx90QzUAZsyJ2gKzq8tJIx/K07h39otq1FYo/0VKhwa65w+?=
 =?us-ascii?Q?RTQ45QEGvdRpDOKvUrqJji7AVK5W1ti3mpznbKr67En1rFvWYUTIuZr03um7?=
 =?us-ascii?Q?CU+z2CqVn8YWs41vKQAl0E9A+jcM+3O36wOfgSlPrX72KORQitF/tXtpvlJf?=
 =?us-ascii?Q?r0cetTBjLrFhn4z5o0CG9j3LoGseywv56XehXVuihSTt1eCx9deKX6yNJW/9?=
 =?us-ascii?Q?sPc09fAWULoGhtTF6soYjwNcYrMHPygqwX+tLFung7h7sZEdAi8iqVYlXTyt?=
 =?us-ascii?Q?hIt7oyeva3QnSCWhjOcndM0Nyj+0N+NmGu8zqLqqw4lpNVeOXZNxx6HV8mRf?=
 =?us-ascii?Q?mjAhZZZubKCHHrA+CC/aWh9bkmEXdN2AXL5o3lJXbJzHi6SFCgVrXZptyTh/?=
 =?us-ascii?Q?ip85OPc1dPdanExulQFjYPw7ig2A4KOFAk4ocyo3X1Kk0gwsTkTJoCeaxWbS?=
 =?us-ascii?Q?uzWxOvqRBDIUbfpweNcfwRztttSOE2Wp+45pqbq+iPvHZHd82UNKGw=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D6A5A95DDB6E334192B92D2F53927CA1@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ebbc2aa-eba0-4cf5-b08f-08da0c3ea4e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2022 20:00:41.9234
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Qhmn0aL5A+RJv7fIzYq1bIzsi/TL7F536LF5yUhLezjRPNRBJRV1gLRgJZpiTBCsPJ9UU8xo3fDKNfiUfHl0VA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4577
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10294 signatures=694350
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0
 bulkscore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2203220104
X-Proofpoint-GUID: QXG2wYhpgC8bhfLtA8QHUS4cV0FrYaJu
X-Proofpoint-ORIG-GUID: QXG2wYhpgC8bhfLtA8QHUS4cV0FrYaJu
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Mar 14, 2022, at 8:41 PM, NeilBrown <neilb@suse.de> wrote:
>=20
> On Tue, 15 Mar 2022, Chuck Lever III wrote:
>> Hi Neil-
>>=20
>>> +.IP \- 2
>>> +NFS-root (diskless) clients, where the DCHP server (or equivalent) doe=
s
>>> +not provide a unique host name.
>>=20
>> Suggest this addition:
>>=20
>> .IP \- 2
>>=20
>> Dynamically-assigned hostnames, where the hostname can be changed after
>> a client reboot, while the client is booted, or if a client often=20
>> repeatedly connects to multiple networks (for example if it is moved
>> from home to an office every day).
>=20
> This is a different kettle of fish.  The hostname is *always* included
> in the identifier.  If it isn't stable, then the identifier isn't
> stable.
>=20
> I saw in the history that when you introduced the module parameter it
> replaced the hostname.  This caused problems in containers (which had
> different host names) so Trond changed it so the module parameter
> supplemented the hostname.
>=20
> If hostnames are really so poorly behaved I can see there might be a
> case to suppress the hostname, but we don't have that option is current
> kernels.  Should we add it?

I didn't fully understand this comment before. I assume you are
referring to:

55b592933b7d ("NFSv4: Fix nfs4_init_uniform_client_string for net namespace=
s")

That will likely break reboot recovery if the container's nodename
changes over a reboot.

My (probably limited) understanding is that using the udev rule to
always add a uniquifier could have helped make it possible to remove
the hostname from the co_ownerid.

For the record, I take back this statement:

> I don't think we need to
> exclude the hostname from the nfs_client_id4 -- in fact some folks
> might prefer keeping the hostname in there as an eye-catcher. But
> it's simply that the hostname by itself does not provide enough
> uniqueness.


Since the nodename can change at inopportune times (like over a
reboot), including it in the co_ownerid string can sometimes be
problematic. But I don't have a better suggestion at this time.


> This conversation seems to be going around in circles and not getting
> anywhere.  As as I have no direct interest (the SUSE bugzilla has
> precisely 1 bug relating to NFS and non-unique hostnames, and the
> customer seemed to accept the requirement of unique hostnames) I am
> going to bow out.  I might post one more attempt at a documentation
> update ... or I might not.

I now agree that the Linux NFS community will need to work with
packagers and distributors, and that we will not arrive at a one-
size-fits-all tool by ourselves.

I'll try to pick up the documentation torch. Thanks for your
efforts so far.


--
Chuck Lever