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:     Trond Myklebust <trondmy@hammerspace.com>
CC:     "dan@kernelim.com" <dan@kernelim.com>,
        "bcodding@redhat.com" <bcodding@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Anna Schumaker <schumaker.anna@gmail.com>
Subject: Re: [PATCH v2 0/5] SUNRPC: Create sysfs files for changing IP
Thread-Topic: [PATCH v2 0/5] SUNRPC: Create sysfs files for changing IP
Thread-Index: AQHW+ZPDkI44uVsPcUiYIRmrZ1p/T6pFNZQAgAAASgCAAAj5gIAABxUAgAApaYCAAAD3AA==
Date:   Tue, 2 Feb 2021 22:21:19 +0000
Message-ID: <102D99DF-30C7-4360-9A84-D5A4DA77FE1C@oracle.com>
References: <20210202184244.288898-1-Anna.Schumaker@Netapp.com>
 <75F3F315-84AA-41A0-A43A-C531042A9C47@oracle.com>
 <CAFX2JfktYGe4vDtXogFHurdyz4TJx5APj9pb-J5HmsDGC99kaA@mail.gmail.com>
 <20210202192417.ug32gmuc2uciik54@gmail.com>
 <8A686173-B3FF-4122-990C-6E8795D35161@redhat.com>
 <7dfd7e3b9fb39da71f1654347ca2f2feba4fc04d.camel@hammerspace.com>
In-Reply-To: <7dfd7e3b9fb39da71f1654347ca2f2feba4fc04d.camel@hammerspace.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C904FD9E5C0FA24D94C6C44EB5A2008D@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c39bb532-c08e-417e-64d3-08d8c7c8dd6b
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2021 22:21:19.4238
 (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: BhVJHJGLJFRWTnWzcH/zR58PDIeoLjSw70WK4XVzToFNkYhpJhcfuDRwL6L+fidZk6ZI56gChpuxBQ+iijjdaA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3462
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9883 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 suspectscore=0
 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2102020141
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=9883 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0
 mlxscore=0 spamscore=0 bulkscore=0 priorityscore=1501 adultscore=0
 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxlogscore=999
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2102020141
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 2, 2021, at 5:17 PM, Trond Myklebust <trondmy@hammerspace.com> wro=
te:
>=20
> On Tue, 2021-02-02 at 14:49 -0500, Benjamin Coddington wrote:
>> On 2 Feb 2021, at 14:24, Dan Aloni wrote:
>>=20
>>> On Tue, Feb 02, 2021 at 01:52:10PM -0500, Anna Schumaker wrote:
>>>> You're welcome! I'll try to remember to CC him on future versions
>>>> On Tue, Feb 2, 2021 at 1:51 PM Chuck Lever
>>>> <chuck.lever@oracle.com> wrote:
>>>>>=20
>>>>> I want to ensure Dan is aware of this work. Thanks for posting,
>>>>> Anna!
>>>=20
>>> Thanks Anna and Chuck. I'm accessing and monitoring the mailing
>>> list via
>>> NNTP and I'm also on #linux-nfs for chatting (da-x).
>>>=20
>>> I see srcaddr was already discussed, so the patches I'm planning to
>>> send
>>> next will be based on the latest version of your patchset and
>>> concern
>>> multipath.
>>>=20
>>> What I'm going for is the following:
>>>=20
>>> - Expose transports that are reachable from xprtmultipath. Each in
>>> its
>>>   own sub-directory, with an interface and status representation
>>> similar
>>>   to the top directory.
>>> - A way to add/remove transports.
>>> - Inspiration for coding this is various other things in the kernel
>>> that
>>>   use configfs, perhaps it can be used here too.
>>>=20
>>> Also, what do you think would be a straightforward way for a
>>> userspace
>>> program to find what sunrpc client id serves a mountpoint? If we
>>> add an
>>> ioctl for the mountdir AFAIK it would be the first one that the NFS
>>> client supports, so I wonder if there's a better interface that can
>>> work
>>> for that.
>>=20
>> I'm a fan of adding an ioctl interface for userspace, but I think
>> we'd
>> better avoid using NFS itself because it would be nice to someday
>> implement
>> an NFS "shutdown" for non-responsive servers, but sending any ioctl
>> to the
>> mountpoint could revalidate it, and we'd hang on the GETATTR.
>>=20
>> Maybe we can figure out a way to expose the superblock via sysfs for
>> each
>> mount.
>=20
> Right. There is potential functionality here that we do not need or
> even want to expose via the mount interface. Being able to cancel all
> the hung RPC calls in an RPC queue, for instance, is not something you
> want to do through fsopen() and friends.

I thought we were talking only about an ioctl or fsopen cmd that
identifies the transports that are associated with an NFS mount.

Ostensibly a read-only use of that API.


--
Chuck Lever