[ENBD] Re: ENBD on Debian 2.6.7/8 kernel

[P.T. Breuer]

In article <4159ED6A.5070502 at ociweb.com> you wrote:

> P.T. Breuer wrote:

> | 2.4.31 is not tested with the 2.6.7 kernel patch (but it should
> | work, since the patch  is the same as the 2.6.3 patch, to all
> | intents and purposes). Please use 2.4.32 and tell me how it works
> | in make test, in the basic configuration, after giving me the
> | compiler and compile options used.


> make test seemed to work fine after I copied the enbd.ko and
> enbd_ioctl.ko files to enbd.o and enbd_ioctl.o in /tmp.

OK, that's great.

> It gave
> successful output for everything that it did. 

> I set the compiler to
> gcc-2.95 in the Makefile for both CC= and KCC=.  However, when I went

Hmm. Ideal lyit should match your kernel compiler, and your kernel
should be compiled with a cmpiler as safe as that!

> to start enbd-client like this:

> enbd-client storagenode1 10350 -n 4 -i disk1 /dev/ndf

That's deprecated syntax, but it may work. SHould probably be:

  
  enbd-client storagenode1:10350 -n 4 -i disk1 /dev/ndf


> (I used /dev/ndf since the make test didn't clean up after itself and

Oh - that's a good idea, you know. I'll add that. I alsways assumed
people would like to see the setup running afterwards, but I guess by
default it could stop the thing.

> was still running about 4 enbd-client and enbd-server processes to
> localhost.)

Well, that is the intention: to setup a "test" setup as an example.
You can run tests on the thing.

> enbd-client complained about not giving it a device on the command
> line until I used enbd-client storagenode1:10350 ...

I would have expected that. It's hard to distinguish between the words
supplied on the command line by look alone - only you know what they
really mean!

> | Yes. But that is not your aim - the aim is to build something that
> | works. You can package it later if it does!


> I was attempting to use this on a system without installing any
> sources or compilation tools.  Guess I was hoping for too much at the
> moment.

Hmm. Interesting.

> I've done that now with my "build machine" which is not running the
> kernel that the modules have been built for.  I copy them over to my
> "clean" machines to do the testing.

OK.


> | That's consistent with the observation that the initial handshake
> | never completed. So it doesn't look like a kernel thing since it
> | never gets as far as using the kernel - try the same daemons on a
> | 2.4 platform to confirm.

> Hmm.  My test scenario currently has an LVM2 volume setup.  I was
> hoping to not have to use the 2.4 kernel.

OK - I have patched the 2.4 kernel for dm, which enables me to use lvm2
on it also. Never mind then, I'm compiling a 2.6.7 uml and I'll test
under it.


> |> |> nbd/alarm  2676: <# 131> unchain_current_ualarm signalling
> |> ALRM |> for late (-334.411163s) alarm 0xbfffe000   <-- at this
> |> point, the |>  enbd-client processes are dead; /var/run/enbd-* |
> |> | | Looks like you have alarm problems. The timings are way off.
> |> But | anyway, handshake never completed - it timed out. This has
> |> symptoms | of compiler problems.


> I am still getting these error messages when I attempt to bring the
> devices up manually on the client side.  However, I did notice that
> compiling with the default gcc (3.x something) causes prolific
> compiler warnings about functions not inlining successfully.  When I
> compiled with gcc-2.95, those messages didn't appear.

They MUST inline.  At least ome of the ones that are directed to inline
are intended to inline for their functionality. But I have gcc-3.4 and
I get no such conplaints. Can it be that you have an earlier 3. gcc?
All the 3. series are buggy to one extent or another, which is why I
will not use them on a kernel.

> I had to untar enbd-2.4.32 into /usr/src and cd into that directory
> (/usr/src/nbd-2.4.32) before enbd-maketest works.

--bindir=/usr/sbin, but I believe you, since I have never used it
except as part of "make test", which calls it from the archive
directory. I'll try it from somewhere else as soon as I have the 2.6.7
uml compiled.

Peter