Re: kernel inclusion planned?

"Also sprach Stephan von Krawczynski:"
> I am one of those who think kernel inclusion would be a desirable thing. My
> major reasons are:
> 1) enbd needs more "eyes". 

I agree.

> Every now and then I set up an enbd-testbed to find out how things are going.
> The last one was some weeks ago and it was  - again - not quite successful.
> Setup worked as usual quite ok, but the boxes crashed when I stressed the
> enbd-raid 1 (with fr)(*). This was not the first time that happened to me,
> effectively all former tests ended more or less that way. Up to now I have

Then you want to publish the test so that the problem can be
reproduced for investigation.  You also want to check out which
versions of enbd in combination with which version of the kernel
reproduce the problem, and most importantly, which do not.

> only managed to set up one box working quite ok (ok, I do not stress this one,

I should add that the enbd code behaves in no way differently when it is
"stressed" than when it is not.  It's a very boring character ...  it
just does the same old procedure over and over again.  So saying that
there is a problem when it is "stressed" is really saying that the
problem does not lie entirely within the code itself, but is an
interaction of the code with something else, some other code, or some
environmental circumstance.  To find that out, one has to vary the
parameters in the experiment to see what that something else might be.

I can imagine for example, that writing to the device through raid at
full speed with multiple daemon threads running on an smp machine might
trigger a race condition within the driver that is not obvious.  Very
well then, run it on a UP machine and see if the same thing happens.  If
it doesn't, problem indicated.

Or try running with only one daemon thread, and see how that affects
the experiment.  It would effectively serialize transfers in userspace.
One can then go on to ask for serialization even within the kernel by
setting the enbd request queue maxlength to 1.  I'm very happy to
arrange for such experiments!  Indeed, getting experiments like that set
up is what is really needed.

Another thing that often has me worried is whether the kernel needs or
has buffers for use in ioctls even when it is otherwise out of memory
(as when you fill memory with buffers by writing to the device faster
than data can be treated).  There is an obvious resource competetition
with tcp for buffers to send data out too, in that situation (supposedly
resolved in the kernel memory manager in favor of networking always, but
I am dubious that the "always" is for real). Varying the experiment to
included kernels with different memory managers would show whether
there is a problem there (I always hated it when the kernel's
free-memory-by-flushing-random-devices algorithm was not random but
deterministic, which meant it might have tried to free enbd memory by
freeing raid memory, repeatedly, which wouldn't work when the two are
linked ..  I really hope the mm is non-deterministic nowadays!).

One of the things I would like to do is give the option of an in-kernel
daemon cycle, and maybe more paremeters so that the things I just
mentioned can be tested directly by users (again with the aim of
getting more testing done). But I am heavily overworked at the meoment
and cannot do such testing myself ... my favorite SMP testbed machine is
still at 2.4.17rc2 (or 2.6.12.3) and my portable is on 2.6.15.4. My 64
bit amd machine is on 2.6.15.5.

But at the end of the day, good testing is essential.

Peter