[ENBD] Re: Enhanced NBD daemon on 2.4.3 kernel

[Peter T. Breuer]

"A month of sundays ago Jason A. Pattie wrote:"
> Peter T. Breuer wrote:
> > "A month of sundays ago Jason A. Pattie wrote:"
> > 
> >> On an off-hunch, I started nbd-client (2.4.23) with 4 aliases to the 
> >> same IP address instead of only 1.  Now, I'm swapping just fine over the 
> > 
> > This means that you have somehow magicked swapping into being?! enbd was
> > never supposed to support swapping (swapping over the net strikes me as
> > crazy and I eliminated it from considerations early on).
> 
> I wanted to eventually get to the point where I could use the SSL 
> encrypted session to secure the virtual memory pages in transit across 
> the network.

Oh, I see. Isn't there an official swapping-over-the-net patch? I
honestly don't see how you can use tcp for swapping. You have to
"fire and hope" or you'll deadlock waiting for a write to swap
to release the buffers, while needing those buffers to read the 
results.

> > If you are swapping, then what happens if some of the nbd code is
> > swapped out? I seem to recall that that was the fundamental issue!
> > It can't work if one's running synchronously. And nbd DOES run sync
> 
> The NFS swapping patch gets around this by always running 
> asynchronously.  I just read it on the author's homepage.  I don't know 
> exactly what this means, but he said it causes transfers to slow down 
> vs. running synchronously.

Hmm. I would have thought the opposite.

> > With more than one thread running, it may be that you get out of
> > deadlock by letting the other thread retrieve the code that the first
> > thread needs. But I still think it will lock up eventually. If not
> > in nbd, then in tcp, or in vfs.
> 
> I'm sure you're right.
> 
> > I have enabled an "async" option in my latest client code. The client
> > lies to the kernel that it has sent the packet when it hasn't yet.
> 
> Would this help me?

You might as well be the first person to try it. -a to the client.

Peter