On 14 May 2021, at 10:16, Olga Kornievskaia wrote:
On Fri, May 14, 2021 at 6:17 AM Benjamin Coddington
<bcodding@xxxxxxxxxx> wrote:
The information isn't lost, as the symlink points to the specific
switch.
Not using a number in the symlink name informs that there will only
be one
switch for each client and makes it more deterministic for users and
software to navigate.
What will be lost is that when you look at the xprt_switches directory
and see switch-1... switch-10 subdirectory, there is no way to tell
which rpc client uses which switch. Because each client-1 directory
will only have an entry saying "switch".
Anyway, I submitted the new version but I think it's not as good as
the original.
Hmm, ok - will we ever need to traverse objects in that direction
though?
I'm thinking that operations on xprts/rpcs will always start from a
mount
perspective from the admin, but really the root object is struct
nfs_server,
or bdi. I'm thinking of something like:
/sys/fs/nfs/<bdi>/rpc_clnt -> ../../net/sunrpc/clnt-0
/sys/fs/nfs/<bdi>/volumes
...
I suppose though you could have something monitoring the xprts, and upon
finding a particular state would want to navigate back up to see what
client
is affected. At that point you'd have to read all the symlinks for all
the
rpc_clients.
Ben
