Re: Closing enbd devices

Thanks for a very quick reply! (And for bringing us an excellent
project)

> Oh, I see. That's what you mean! It's not really intended to be used
> with a different remote resource. That would be like changing your hard
> disk without telling the IDE subsystem.

About intended...well, I guess enbd is really intended for remote
RAIDing? But luckily you have put in efforts for making it easier for us
who wants to (ab?)use it for doing remote media solutions. So yes, it is
not intended for it, but I still want to do it :-) (it's the best tool
for the job, even if it isn't really made for it)

> Well, nowadays the server always generates the same (pseudo random)
> signature for the same resource. So you shouldn't notice anything if
> you don't give the signature and then reconnect, provided nothing
> changed.

That's the thing: Things changes!

Longer explanation: What I'm doing is for a LTSP network. So the task is
to connect any media that is ever plugged into a thin-client on the
network to ENBD on the server. The removable devices aren't statically
configured, but enbd-links are set up dynamically when plugging in the
devices (by the use of a monitoring daemon on the thin-client, and a
service on the server accepting requests to connect or disconnect
to/from devices). Reasons for this:

While N NDB units is sufficient for the number of _concurrently_
connected removable media on the entire network, N is not sufficient for
the total number of devices ever connected. For starters, LTSP uses
kernel 2.4 on thin-clients, where each new USB device get a new SCSI
device. Also for big organizations with more than a hundred connected
clients (not unheard of), the volume alone means that N is too small for
any number of N, if you think one nbd per device ever connected (quickly
more than one per client, even if the concurrent number of removable
media is much lower).

Well, I guess in practice you can build nbd with enough devices, but
leaving stale devices never to be used again is still bad coding.

Yes, there are tricks to get around this (reloading usb-storage.o when
no USB devices are connected helps a lot), however they can only be
kludges to the underlying problem. The solution doesn't scale, and it
potentially adds a lot of unecessary manual configuration.

So when done using a nbd I want to totally close it off and reuse it.
Think "pool". The original media is long since unplugged and unmounted
by the time I reuse it, so the chances of a reconnection isn't there
from the user side of thing. What the kernel thinks I do not know (see
end). Nice and simple conceptually: There's a limit on concurrently
connected devices, but no limits otherwise.

The point is that I want the closing to be a conscious decision. It
shouldn't happen automatically when all enbd-clients exit, ideally there
would be a seperate method for it (seperate app, or "echo close b
> /dev/ndbinfo").

<snip>

Thanks a lot for the information on how to disable the signature
requirement, it does give me a working solution. However not a perfect
one:

- The signature stuff is nice to have _while the connection is supposed
to stay up_. I want closing down an nbd device to be a conscious
decision done by the removable media service, the ability to reconnect
is great to have.
- It isn't that pure. For instance my service must currently seperately
keep track of available nbd devices, rather than asking enbd for a free
device (through parsing /proc/nbdinfo, probably). And I can't
monitor /proc/nbdinfo to get the "real" state of connected devices. So
the pooling happens one layer above where it should (in my opinion, that
is) happen.

Perhaps, if the kernel needs the device present, it would be possible to
keep it open from the kernel side, but report it closed to userspace?
Certainly the change of underlying data can't matter, I mean I do change
the CD-ROMS under the IDE subsystem...

I am aware that there might be big problems with this idea
implementation-wise. I am a coder but I have never touched kernel source
more than briefly. Please enlighten me!

// Dag Sverre