Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever <chuck.lever@oracle.com>
To:     Olga Kornievskaia <aglo@umich.edu>,
        Anna Schumaker <schumaker.anna@gmail.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH 0/7] SUNRPC: Create sysfs files for changing IP
Thread-Topic: [RFC PATCH 0/7] SUNRPC: Create sysfs files for changing IP
Thread-Index: AQHW7nt7AQ6ZiPdlo0OD3oTA8gSlCg==
Date:   Tue, 19 Jan 2021 15:55:18 +0000
Message-ID: <1C4287BD-6772-47A9-B5C4-054CC99C7E05@oracle.com>
References: <20210111214143.553479-1-Anna.Schumaker@Netapp.com>
 <CE510EA5-1E3F-4516-A948-10A0FF31C94F@oracle.com>
 <20210112165911.GH9248@fieldses.org>
 <CAFX2JfmYrCSYfCCGgQ0eghU3WSqk=T38wxkJ7Q42ORw-NFeFQg@mail.gmail.com>
 <7003D8A9-3B95-4B36-84EC-99D4D1806366@oracle.com>
 <5EBDAA40-4F55-4EF2-956D-9877C4F4A9A7@oracle.com>
 <CAN-5tyF=qQbmBPXY7HDAEReidYYqFsV-dFrtkqqJfRAsxtyu8A@mail.gmail.com>
In-Reply-To: <CAN-5tyF=qQbmBPXY7HDAEReidYYqFsV-dFrtkqqJfRAsxtyu8A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <DFA17299CF599C41BCE810B640BB1CA6@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 94edf8ed-0329-457d-ecae-08d8bc929edd
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2021 15:55:18.8809
 (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: uRMR/tP6ty7s2XvV9wQASIuEVqHXSwpaEkyMayUDH9I4gcFHZ5tFCPTNAwfhTPSJynjRZHPQHOxqO9v8PkctRw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2920
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9868 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0
 phishscore=0 mlxscore=0 adultscore=0 spamscore=0 bulkscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2101190094
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9869 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 spamscore=0
 mlxlogscore=999 clxscore=1015 bulkscore=0 adultscore=0 lowpriorityscore=0
 suspectscore=0 phishscore=0 mlxscore=0 malwarescore=0 priorityscore=1501
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2101190094
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jan 14, 2021, at 3:29 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
>=20
> On Wed, Jan 13, 2021 at 9:18 PM Chuck Lever <chuck.lever@oracle.com> wrot=
e:
>>=20
>>=20
>>> On Jan 13, 2021, at 2:48 PM, Chuck Lever <chuck.lever@oracle.com> wrote=
:
>>>=20
>>>> On Jan 13, 2021, at 2:23 PM, Anna Schumaker <schumaker.anna@gmail.com>=
 wrote:
>>>>=20
>>>> On Tue, Jan 12, 2021 at 11:59 AM J. Bruce Fields <bfields@fieldses.org=
> wrote:
>>>>>=20
>>>>> On Tue, Jan 12, 2021 at 08:09:09AM -0500, Chuck Lever wrote:
>>>>>> Hi Anna-
>>>>>>=20
>>>>>>> On Jan 11, 2021, at 4:41 PM, schumaker.anna@gmail.com wrote:
>>>>>>>=20
>>>>>>> From: Anna Schumaker <Anna.Schumaker@Netapp.com>
>>>>>>>=20
>>>>>>> It's possible for an NFS server to go down but come back up with a
>>>>>>> different IP address. These patches provide a way for administrator=
s to
>>>>>>> handle this issue by providing a new IP address for xprt sockets to
>>>>>>> connect to.
>>>>>>>=20
>>>>>>> This is a first draft of the code, so any thoughts or suggestions w=
ould
>>>>>>> be greatly appreciated!
>>>>>>=20
>>>>>> One implementation question, one future question.
>>>>>>=20
>>>>>> Would /sys/kernel/net be a little better? or /sys/kernel/sunrpc ?
>>>>=20
>>>> Possibly! I was trying to match /sys/fs/nfs, but I can definitely
>>>> change this if another location is better.
>>>=20
>>> Ah... since this is a supplement to the mount() interface, maybe
>>> placing this new API under /sys/fs/nfs/ might make some sense.
>>=20
>> Or you could implement it with "-o remount,addr=3Dnew-address".
>=20
> A change of address is currently not allowed by the NFS because
> multiple mounts might be sharing a superblock and change of one
> mount's option would not be correct. The way things work from this new
> mechanism is system wide and all mounts are affected.

OK, well, if we're going with an API based on /sys that shows
underlying transport connections, is there a way to expose
whether the connection is established or closed? Maybe also
last traffic or last connect attempt?

Can it support RPC/RDMA connections too?


--
Chuck Lever