Re: [Nbd] nbd-client: (no?) way to find out connected hosts

[Stefan Tauner <stefan.tauner@...2871...>]

On Mon, 20 Mar 2017 08:55:21 +0100
Wouter Verhelst <w@...112...> wrote:

> On Mon, Mar 20, 2017 at 02:24:50AM +0100, Stefan Tauner wrote:
> > Hi,
> > I am writing backup scripts around nbd-client currently and ran into
> > an issue. I would like to be able to determine the remote site of a
> > given /dev/nbd*. I could probably hack something with pgrep
> > nbd-client and the corresponding /proc/$pid/cmdlines but I would
> > definitely prefer a built-in solution that won't explode now and then ;)  
> 
> Did you consider parsing the output of 'netstat' (or the symlinks under
> /proc/$pid/fd) to see where the sockets point?

Well, it wouldn't change anything significantly in my opinion - it is
still way more work than it should be, especially since it should be
rather easy within the kernel to determine and report this
information back(?).

> Otherwise, there's just no way to do that reliably currently. When a
> device is running, nbd-client is in IO-wait state and remains there
> until the device disconnects, so you can't send it any queries. Asking
> the kernel would be possible, but there's no API for that.

I was expecting that and thought I could try to spark a discussion
within the project if that wouldn't make sense ;)
Maybe some sysfs files that export other configuration and run-time
data as well (whatever is available within the kernel and possibly
useful for userland, e.g. transferred bytes, age of the connection).

> 
> At any rate, you don't need to pgrep -- there's nbd-client -c which
> tells you the PID of the process that holds a device, if connected.

But one needs to iterate over all devices...

> 
> > Also, it would be nice to be able to call nbd-client so that it uses
> > the first free /dev/nbd* if any (similar to losetup -f file).  
> 
> This will be available with the new netlink interface that Josef wrote
> recently, but it's not been merged into Linus' tree AFAICS.

Cool, thanks to both of you.

For my small use case I have decided to simply restrict myself to a
single device for now... and rely on a fixed device path.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner