RE: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

RE: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Nagendra Tomar]

Hi Anna,
     We have a similar but slightly different requirement.
You change allows a user to force a xprt's remote address to anything, allowing
it to connect to a different address than what it originally had.
The original server/xprt address starts as the one that userspace mount program
provides, possibly after resolving the servername used in the mount command.

Our requirement is that that server name remains same but its address changes, 
aka, DNS failover.
Such cases (which I believe are more common) can be handled fully automatically,
by resolving the server name before every xprt reconnect. CIFS does this.
NFS also has fs/nfs/dns_resolve.c which we can use to do the name resolution,
though it's currently not being used for this specific use.

Did you have a similar requirement in mind, and/or did you consider the above?
Would like to know your thoughts.

Thanks,
Tomar

-----Original Message-----
From: Anna Schumaker <schumakeranna@gmail.com> On Behalf Of schumaker.anna@gmail.com
Sent: 13 March 2021 02:48
To: linux-nfs@vger.kernel.org
Cc: Anna.Schumaker@Netapp.com
Subject: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

From: Anna Schumaker <Anna.Schumaker@Netapp.com>

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 administrators to
handle this issue by providing a new IP address for xprt sockets to
connect to.

Chuck has suggested some ideas for future work that could also use this
interface, such as:
- srcaddr: To move between network devices on the client
- type: "tcp", "rdma", "local"
- bound: 0 for autobind, or the result of the most recent rpcbind query
- connected: either true or false
- last: read-only timestamp of the last operation to use the transport
- device: A symlink to the physical network device

Changes in v3:
- Rename functions and objects to make future expansion easier
- Put files under /sys/kernel/sunrpc/client/ instead of
  /sys/kernel/sunrpc/net/, again for future expansions
- Clean up use of WARN_ON_ONCE() in xs_connect()
- Fix up locking, reference counting, and RCU usage
- Unconditionally create files so userspace tools don't need to guess
  what is supported (We return an error message now instead)

Changes in v2:
- Put files under /sys/kernel/sunrpc/ instead of /sys/net/sunrpc/
- Rename file from "address" to "dstaddr"

Thoughts?
Anna


Anna Schumaker (5):
  sunrpc: Create a sunrpc directory under /sys/kernel/
  sunrpc: Create a client/ subdirectory in the sunrpc sysfs
  sunrpc: Create per-rpc_clnt sysfs kobjects
  sunrpc: Prepare xs_connect() for taking NULL tasks
  sunrpc: Create a per-rpc_clnt file for managing the destination IP
    address

 include/linux/sunrpc/clnt.h |   1 +
 net/sunrpc/Makefile         |   2 +-
 net/sunrpc/clnt.c           |   5 +
 net/sunrpc/sunrpc_syms.c    |   8 ++
 net/sunrpc/sysfs.c          | 191 ++++++++++++++++++++++++++++++++++++
 net/sunrpc/sysfs.h          |  20 ++++
 net/sunrpc/xprtsock.c       |   2 +-
 7 files changed, 227 insertions(+), 2 deletions(-)
 create mode 100644 net/sunrpc/sysfs.c
 create mode 100644 net/sunrpc/sysfs.h

-- 
2.29.2

Re: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Olga Kornievskaia]

Hi Tomar,

SUNRPC layer only deals with resolved addresses not dns names (on
purpose). DNS resolution code that does exists at the NFS layer is for
referrals/migration -- an event that happens at a point in time and
doesn't repeat (but it does implement a simple caching strategy). At
the SUNRPC layer, a connection can be dropped and re-established
numerous times and thus, to require DNS resolution on each attempt
will interfere with performance because a DNS resolution requires an
upcall into the userland (implementing DNS caching at the SUNRPC layer
is a non-starter probably, since policy based features should be in
userland).

You mention that you are interested in using the "same" server only
changing the IP. DNS failover is no way an authority in "sameness" of
the server. NFSv4.x have definitions of what it means to call 2
servers the same. When doing an IP change via a SUNRPC layer, we are
relying on the fact that an administrator will be pointing it to the
"same" server.

Given that a failover is an "event", an administrator can do a DNS
query and then use the provided IP to supply into the sysfs to direct
the IO to the new server IP. Maybe the sysfs interface can support
receiving a DNS name and doing a DNS lookup then (but that probably
should be an addition onto these patches not in the initial version)?


On Fri, Mar 19, 2021 at 9:27 PM Nagendra Tomar
<Nagendra.Tomar@microsoft.com> wrote:
>
> Hi Anna,
>      We have a similar but slightly different requirement.
> You change allows a user to force a xprt's remote address to anything, allowing
> it to connect to a different address than what it originally had.
> The original server/xprt address starts as the one that userspace mount program
> provides, possibly after resolving the servername used in the mount command.
>
> Our requirement is that that server name remains same but its address changes,
> aka, DNS failover.
> Such cases (which I believe are more common) can be handled fully automatically,
> by resolving the server name before every xprt reconnect. CIFS does this.
> NFS also has fs/nfs/dns_resolve.c which we can use to do the name resolution,
> though it's currently not being used for this specific use.
>
> Did you have a similar requirement in mind, and/or did you consider the above?
> Would like to know your thoughts.
>
> Thanks,
> Tomar
>
> -----Original Message-----
> From: Anna Schumaker <schumakeranna@gmail.com> On Behalf Of schumaker.anna@gmail.com
> Sent: 13 March 2021 02:48
> To: linux-nfs@vger.kernel.org
> Cc: Anna.Schumaker@Netapp.com
> Subject: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address
>
> From: Anna Schumaker <Anna.Schumaker@Netapp.com>
>
> 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 administrators to
> handle this issue by providing a new IP address for xprt sockets to
> connect to.
>
> Chuck has suggested some ideas for future work that could also use this
> interface, such as:
> - srcaddr: To move between network devices on the client
> - type: "tcp", "rdma", "local"
> - bound: 0 for autobind, or the result of the most recent rpcbind query
> - connected: either true or false
> - last: read-only timestamp of the last operation to use the transport
> - device: A symlink to the physical network device
>
> Changes in v3:
> - Rename functions and objects to make future expansion easier
> - Put files under /sys/kernel/sunrpc/client/ instead of
>   /sys/kernel/sunrpc/net/, again for future expansions
> - Clean up use of WARN_ON_ONCE() in xs_connect()
> - Fix up locking, reference counting, and RCU usage
> - Unconditionally create files so userspace tools don't need to guess
>   what is supported (We return an error message now instead)
>
> Changes in v2:
> - Put files under /sys/kernel/sunrpc/ instead of /sys/net/sunrpc/
> - Rename file from "address" to "dstaddr"
>
> Thoughts?
> Anna
>
>
> Anna Schumaker (5):
>   sunrpc: Create a sunrpc directory under /sys/kernel/
>   sunrpc: Create a client/ subdirectory in the sunrpc sysfs
>   sunrpc: Create per-rpc_clnt sysfs kobjects
>   sunrpc: Prepare xs_connect() for taking NULL tasks
>   sunrpc: Create a per-rpc_clnt file for managing the destination IP
>     address
>
>  include/linux/sunrpc/clnt.h |   1 +
>  net/sunrpc/Makefile         |   2 +-
>  net/sunrpc/clnt.c           |   5 +
>  net/sunrpc/sunrpc_syms.c    |   8 ++
>  net/sunrpc/sysfs.c          | 191 ++++++++++++++++++++++++++++++++++++
>  net/sunrpc/sysfs.h          |  20 ++++
>  net/sunrpc/xprtsock.c       |   2 +-
>  7 files changed, 227 insertions(+), 2 deletions(-)
>  create mode 100644 net/sunrpc/sysfs.c
>  create mode 100644 net/sunrpc/sysfs.h
>
> --
> 2.29.2
>
>

RE: [EXTERNAL] Re: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Nagendra Tomar]

> From: Olga Kornievskaia <aglo@umich.edu>
> Sent: 25 March 2021 00:43
> 
> Hi Tomar,

Hi Olga,
     Thanks for your comments!

> 
> SUNRPC layer only deals with resolved addresses not dns names (on
> purpose). DNS resolution code that does exists at the NFS layer is for
> referrals/migration -- an event that happens at a point in time and
> doesn't repeat (but it does implement a simple caching strategy). At
> the SUNRPC layer, a connection can be dropped and re-established
> numerous times and thus, to require DNS resolution on each attempt
> will interfere with performance because a DNS resolution requires an
> upcall into the userland (implementing DNS caching at the SUNRPC layer
> is a non-starter probably, since policy based features should be in
> userland).

A SUNRPC reconnect is not a fastpath operation. Usually, it's done after
1+ consecutive RPC timeouts which would easily be at least 10's 
of seconds to few minutes. Having a DNS resolution which might take
additional few 10/100's msecs doesn't look like too much extra work IMHO,
given that one of the reasons for server not responding on the old address
could well be because it has moved to a new address (Zone/Geo failovers 
being more likely with cloud based NFS servers).
Also, if user does not have a server that uses DNS failover, she can
simply provide the IP at the time of mount (IP:/share vs Hostname:/share),
and that can act as a hint for the rpc layer to not do resolution on reconnect.

> 
> You mention that you are interested in using the "same" server only
> changing the IP. DNS failover is no way an authority in "sameness" of
> the server. NFSv4.x have definitions of what it means to call 2
> servers the same. When doing an IP change via a SUNRPC layer, we are
> relying on the fact that an administrator will be pointing it to the
> "same" server.

I don't think we are depending on the admin setting "same" server.
I mean we just take the IP on face value and go about our usual RPC state
machine. If the IP happens to point to a different server it will eventually
hit auth failure (for reasonable auth policies) and then we will try to re-setup
auth and fail if we cannot, so admin setting wrong IP cannot break the security
provided by the RPC layer (which is a good thing).
The same should simply work for IP obtained from DNS resolution.

> 
> Given that a failover is an "event", an administrator can do a DNS
> query and then use the provided IP to supply into the sysfs to direct
> the IO to the new server IP. Maybe the sysfs interface can support
> receiving a DNS name and doing a DNS lookup then (but that probably
> should be an addition onto these patches not in the initial version)?

I feel that auto DNS resolution just makes the process more smooth and
intuitive. That's something which to me looks like a more common usage
scenario. The write-ip-to-sysfs approach is definitely generic, but I would
love if it solves the more common DNS failover usecase too.

> 
> 
> On Fri, Mar 19, 2021 at 9:27 PM Nagendra Tomar
> <Nagendra.Tomar@microsoft.com> wrote:
> >
> > Hi Anna,
> >      We have a similar but slightly different requirement.
> > You change allows a user to force a xprt's remote address to anything,
> allowing
> > it to connect to a different address than what it originally had.
> > The original server/xprt address starts as the one that userspace mount
> program
> > provides, possibly after resolving the servername used in the mount
> command.
> >
> > Our requirement is that that server name remains same but its address
> changes,
> > aka, DNS failover.
> > Such cases (which I believe are more common) can be handled fully
> automatically,
> > by resolving the server name before every xprt reconnect. CIFS does this.
> > NFS also has fs/nfs/dns_resolve.c which we can use to do the name
> resolution,
> > though it's currently not being used for this specific use.
> >
> > Did you have a similar requirement in mind, and/or did you consider the
> above?
> > Would like to know your thoughts.
> >
> > Thanks,
> > Tomar
> >
> > -----Original Message-----
> > From: Anna Schumaker <schumakeranna@gmail.com> On Behalf Of
> schumaker.anna@gmail.com
> > Sent: 13 March 2021 02:48
> > To: linux-nfs@vger.kernel.org
> > Cc: Anna.Schumaker@Netapp.com
> > Subject: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address
> >
> > From: Anna Schumaker <Anna.Schumaker@Netapp.com>
> >
> > 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 administrators to
> > handle this issue by providing a new IP address for xprt sockets to
> > connect to.
> >
> > Chuck has suggested some ideas for future work that could also use this
> > interface, such as:
> > - srcaddr: To move between network devices on the client
> > - type: "tcp", "rdma", "local"
> > - bound: 0 for autobind, or the result of the most recent rpcbind query
> > - connected: either true or false
> > - last: read-only timestamp of the last operation to use the transport
> > - device: A symlink to the physical network device
> >
> > Changes in v3:
> > - Rename functions and objects to make future expansion easier
> > - Put files under /sys/kernel/sunrpc/client/ instead of
> >   /sys/kernel/sunrpc/net/, again for future expansions
> > - Clean up use of WARN_ON_ONCE() in xs_connect()
> > - Fix up locking, reference counting, and RCU usage
> > - Unconditionally create files so userspace tools don't need to guess
> >   what is supported (We return an error message now instead)
> >
> > Changes in v2:
> > - Put files under /sys/kernel/sunrpc/ instead of /sys/net/sunrpc/
> > - Rename file from "address" to "dstaddr"
> >
> > Thoughts?
> > Anna
> >
> >
> > Anna Schumaker (5):
> >   sunrpc: Create a sunrpc directory under /sys/kernel/
> >   sunrpc: Create a client/ subdirectory in the sunrpc sysfs
> >   sunrpc: Create per-rpc_clnt sysfs kobjects
> >   sunrpc: Prepare xs_connect() for taking NULL tasks
> >   sunrpc: Create a per-rpc_clnt file for managing the destination IP
> >     address
> >
> >  include/linux/sunrpc/clnt.h |   1 +
> >  net/sunrpc/Makefile         |   2 +-
> >  net/sunrpc/clnt.c           |   5 +
> >  net/sunrpc/sunrpc_syms.c    |   8 ++
> >  net/sunrpc/sysfs.c          | 191 ++++++++++++++++++++++++++++++++++++
> >  net/sunrpc/sysfs.h          |  20 ++++
> >  net/sunrpc/xprtsock.c       |   2 +-
> >  7 files changed, 227 insertions(+), 2 deletions(-)
> >  create mode 100644 net/sunrpc/sysfs.c
> >  create mode 100644 net/sunrpc/sysfs.h
> >
> > --
> > 2.29.2
> >
> >

Re: [EXTERNAL] Re: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Anna Schumaker]

Hi Tomar,

Sorry for not chiming in earlier, as Olga said: I'm on leave (and will
be for several more weeks) after my wife and I had a baby.

On Thu, Mar 25, 2021 at 1:11 AM Nagendra Tomar
<Nagendra.Tomar@microsoft.com> wrote:
>
> > From: Olga Kornievskaia <aglo@umich.edu>
> > Sent: 25 March 2021 00:43
> >
> > Hi Tomar,
>
> Hi Olga,
>      Thanks for your comments!
>
> >
> > SUNRPC layer only deals with resolved addresses not dns names (on
> > purpose). DNS resolution code that does exists at the NFS layer is for
> > referrals/migration -- an event that happens at a point in time and
> > doesn't repeat (but it does implement a simple caching strategy). At
> > the SUNRPC layer, a connection can be dropped and re-established
> > numerous times and thus, to require DNS resolution on each attempt
> > will interfere with performance because a DNS resolution requires an
> > upcall into the userland (implementing DNS caching at the SUNRPC layer
> > is a non-starter probably, since policy based features should be in
> > userland).
>
> A SUNRPC reconnect is not a fastpath operation. Usually, it's done after
> 1+ consecutive RPC timeouts which would easily be at least 10's
> of seconds to few minutes. Having a DNS resolution which might take
> additional few 10/100's msecs doesn't look like too much extra work IMHO,
> given that one of the reasons for server not responding on the old address
> could well be because it has moved to a new address (Zone/Geo failovers
> being more likely with cloud based NFS servers).
> Also, if user does not have a server that uses DNS failover, she can
> simply provide the IP at the time of mount (IP:/share vs Hostname:/share),
> and that can act as a hint for the rpc layer to not do resolution on reconnect.
>
> >
> > You mention that you are interested in using the "same" server only
> > changing the IP. DNS failover is no way an authority in "sameness" of
> > the server. NFSv4.x have definitions of what it means to call 2
> > servers the same. When doing an IP change via a SUNRPC layer, we are
> > relying on the fact that an administrator will be pointing it to the
> > "same" server.
>
> I don't think we are depending on the admin setting "same" server.
> I mean we just take the IP on face value and go about our usual RPC state
> machine. If the IP happens to point to a different server it will eventually
> hit auth failure (for reasonable auth policies) and then we will try to re-setup
> auth and fail if we cannot, so admin setting wrong IP cannot break the security
> provided by the RPC layer (which is a good thing).
> The same should simply work for IP obtained from DNS resolution.
>
> >
> > Given that a failover is an "event", an administrator can do a DNS
> > query and then use the provided IP to supply into the sysfs to direct
> > the IO to the new server IP. Maybe the sysfs interface can support
> > receiving a DNS name and doing a DNS lookup then (but that probably
> > should be an addition onto these patches not in the initial version)?
>
> I feel that auto DNS resolution just makes the process more smooth and
> intuitive. That's something which to me looks like a more common usage
> scenario. The write-ip-to-sysfs approach is definitely generic, but I would
> love if it solves the more common DNS failover usecase too.

I've been thinking of the write-to-sysfs approach as just the kernel
interface. I would expect there to be some future userspace tool built
on the sysfs files that is easier for admins to use. This future tool
could probably be coded to handle dns resolutions and write the result
to the sysfs file.

Thanks,
Anna

>
> >
> >
> > On Fri, Mar 19, 2021 at 9:27 PM Nagendra Tomar
> > <Nagendra.Tomar@microsoft.com> wrote:
> > >
> > > Hi Anna,
> > >      We have a similar but slightly different requirement.
> > > You change allows a user to force a xprt's remote address to anything,
> > allowing
> > > it to connect to a different address than what it originally had.
> > > The original server/xprt address starts as the one that userspace mount
> > program
> > > provides, possibly after resolving the servername used in the mount
> > command.
> > >
> > > Our requirement is that that server name remains same but its address
> > changes,
> > > aka, DNS failover.
> > > Such cases (which I believe are more common) can be handled fully
> > automatically,
> > > by resolving the server name before every xprt reconnect. CIFS does this.
> > > NFS also has fs/nfs/dns_resolve.c which we can use to do the name
> > resolution,
> > > though it's currently not being used for this specific use.
> > >
> > > Did you have a similar requirement in mind, and/or did you consider the
> > above?
> > > Would like to know your thoughts.
> > >
> > > Thanks,
> > > Tomar
> > >
> > > -----Original Message-----
> > > From: Anna Schumaker <schumakeranna@gmail.com> On Behalf Of
> > schumaker.anna@gmail.com
> > > Sent: 13 March 2021 02:48
> > > To: linux-nfs@vger.kernel.org
> > > Cc: Anna.Schumaker@Netapp.com
> > > Subject: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address
> > >
> > > From: Anna Schumaker <Anna.Schumaker@Netapp.com>
> > >
> > > 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 administrators to
> > > handle this issue by providing a new IP address for xprt sockets to
> > > connect to.
> > >
> > > Chuck has suggested some ideas for future work that could also use this
> > > interface, such as:
> > > - srcaddr: To move between network devices on the client
> > > - type: "tcp", "rdma", "local"
> > > - bound: 0 for autobind, or the result of the most recent rpcbind query
> > > - connected: either true or false
> > > - last: read-only timestamp of the last operation to use the transport
> > > - device: A symlink to the physical network device
> > >
> > > Changes in v3:
> > > - Rename functions and objects to make future expansion easier
> > > - Put files under /sys/kernel/sunrpc/client/ instead of
> > >   /sys/kernel/sunrpc/net/, again for future expansions
> > > - Clean up use of WARN_ON_ONCE() in xs_connect()
> > > - Fix up locking, reference counting, and RCU usage
> > > - Unconditionally create files so userspace tools don't need to guess
> > >   what is supported (We return an error message now instead)
> > >
> > > Changes in v2:
> > > - Put files under /sys/kernel/sunrpc/ instead of /sys/net/sunrpc/
> > > - Rename file from "address" to "dstaddr"
> > >
> > > Thoughts?
> > > Anna
> > >
> > >
> > > Anna Schumaker (5):
> > >   sunrpc: Create a sunrpc directory under /sys/kernel/
> > >   sunrpc: Create a client/ subdirectory in the sunrpc sysfs
> > >   sunrpc: Create per-rpc_clnt sysfs kobjects
> > >   sunrpc: Prepare xs_connect() for taking NULL tasks
> > >   sunrpc: Create a per-rpc_clnt file for managing the destination IP
> > >     address
> > >
> > >  include/linux/sunrpc/clnt.h |   1 +
> > >  net/sunrpc/Makefile         |   2 +-
> > >  net/sunrpc/clnt.c           |   5 +
> > >  net/sunrpc/sunrpc_syms.c    |   8 ++
> > >  net/sunrpc/sysfs.c          | 191 ++++++++++++++++++++++++++++++++++++
> > >  net/sunrpc/sysfs.h          |  20 ++++
> > >  net/sunrpc/xprtsock.c       |   2 +-
> > >  7 files changed, 227 insertions(+), 2 deletions(-)
> > >  create mode 100644 net/sunrpc/sysfs.c
> > >  create mode 100644 net/sunrpc/sysfs.h
> > >
> > > --
> > > 2.29.2
> > >
> > >

RE: [EXTERNAL] Re: [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Nagendra Tomar]

> From: Anna Schumaker <anna.schumaker@netapp.com>
> Sent: 25 March 2021 19:26
> Hi Tomar,
> 
> Sorry for not chiming in earlier, as Olga said: I'm on leave (and will
> be for several more weeks) after my wife and I had a baby.

No problem Anna, and congratulations in advance to you and your wife!

> I've been thinking of the write-to-sysfs approach as just the kernel
> interface. I would expect there to be some future userspace tool built
> on the sysfs files that is easier for admins to use. This future tool
> could probably be coded to handle dns resolutions and write the result
> to the sysfs file.

Yeah, I got the idea. I was hoping to avoid any additional userspace tool.
IIUC the userspace tool would be more like an always-running program that 
periodically does the name resolution and updates the sysfs xprt addr
file. It can be done using mount helpers which take the NFS server's hostname
and start the process to periodically resolve the hostname and write to sysfs.
Then on unmount the program has to be stopped.
With the dns resolution upcall on reconnect, all of this could be avoided.
Infact as Olga said, if we extend your patch to treat hostnames specially - 
do dns resolution upcall if the sysfs has the hostname instead of IP address,
that will serve my usecase well too.

Thanks,
Tomar

Re: [EXTERNAL] [PATCH v3 0/5] SUNRPC: Create sysfs files for changing IP address

[Chuck Lever III]

> On Mar 25, 2021, at 11:03 AM, Nagendra Tomar <Nagendra.Tomar@microsoft.com> wrote:
> 
>> I've been thinking of the write-to-sysfs approach as just the kernel
>> interface. I would expect there to be some future userspace tool built
>> on the sysfs files that is easier for admins to use. This future tool
>> could probably be coded to handle dns resolutions and write the result
>> to the sysfs file.
> 
> Yeah, I got the idea. I was hoping to avoid any additional userspace tool.
> IIUC the userspace tool would be more like an always-running program that 
> periodically does the name resolution and updates the sysfs xprt addr
> file. It can be done using mount helpers which take the NFS server's hostname
> and start the process to periodically resolve the hostname and write to sysfs.
> Then on unmount the program has to be stopped.

Well there are variations on this idea. One variation might be
a single orchestrator daemon that would manage the sysfs files
using inotify, so it wouldn't have to track the operation of
mount/umount.

The sysfs files are meant to be only a conduit. User space is
meant to dynamically provide settings based on policy. The
opportunity here is to make this something that can be active
and rules-based instead of a static configuration (ie, more
like udev and less like /etc/fstab).

And note that any solution has to be container-aware. mount
certainly is, and that's another reason why the DNS query is
done at that time. An upcall would have to be done in the same
namespace(s) as the mount was done.

(I'm not advocating any particular approach, merely pointing
out some things that need consideration).


> With the dns resolution upcall on reconnect, all of this could be avoided.
> Infact as Olga said, if we extend your patch to treat hostnames specially - 
> do dns resolution upcall if the sysfs has the hostname instead of IP address,
> that will serve my usecase well too.
> 
> Thanks,
> Tomar

--
Chuck Lever