[ENBD] 20G dd hang up!

[Peter T. Breuer]

More on this before I forget yet AGAIN ...

"A month of sundays ago ptb wrote:"
>   2) you may want to avoid using VM buffers altogether. This is easy in
>   the 2.4 kernels, I believe, because all you have to do is
> 
>      /sbin/raw /dev/raw1 /dev/nda
> 
>   (for example). At least I THINK that is all you have to do. If
>   somebody can confirm, that would be good.
> 
>   In the 2.2 kernels, you may have to apply a patch to get raw i/o.
>   Then you will have to figure out how to make it work! At least the
>   oracle people know how to do that. I think the patch exists, and it 
>   is probably worth searching for it.
> 
>   No buffer use implies no memory contention.

You may also like to get enbd 2.4.27pre1 and try it with the -a switch.
This will make it more "asyncronous". If you discover that it impr÷ves
things, I will supply a "-aa" switch that will make it fully
asyncronous - this should have the effect of permitting network stacks
to be unloaded unconditionally, and shoudl remove any deadlock against 
VM (even though it shouldn't exist, as the 2.4.* kernels demonstrate).

In this mode, nbd trusts the net. It acks a kernel request as soon as
it sends the request out, without waiting for the ack from the server.

In the -aa mode that I'll put in if you say it looks good, nbd will
ack the kernel as soon as it sends the request to userspace, without
waiting either to know if the userspace daemon dealt with it or if
the remote server got it.

Then if you still observe a lockup on kernel 2.2.18, I'm beat.

I put the -s (do swapping) switch in 2.4.27pre1, by the way.

I'm also making some final adjustments to the removable media support.
Unfortunately there is a bug hidden somewhere in the state machine that
handles negotiation of config details between server and client that is
holding me up ... anyone got a generic expect/send engine?

Peter