[ENBD] fixup_slot failed to find slot....

[scunacc]

Dear Peter,

> > I'll try and set it up again at some point to do that and try and strace
> > each process (all 14 of them I guess - to a file), but I am going
> 
> What "14 processes"? Is there something about your setup that you are
> not telling me :-). As I recall you were having compilation problems (I
> don't recall the exact scenario ... was it RH 2.6.9 kernel?). How have
> we jumped to "14 processes" from there?

We dealt with the compilation problems if you recall. Not a problem.

However, as I mentioned in a previous email, I had to move the client
processes to an FC2 machine running 2.6.5

I recompiled kernel and user space there just fine with the couple of
mods you and I have spoken about. 

No problem.

My scenario is this:

(as I did mention before sometime back - but quite a lot of water has
passed ....)

I have 14 blades in a cluster.

Each blade has a SCSI disk.

I have a partition on the disk on each blade that I am serving with
enbd-server.

So

14 enbd-server processes running on 14 machines.

I have one client machine.

Running 14 enbd-client processes - each connecting with a different
identifer to each of the 14 server processes.

Once I then have the nb devices on the client, I then create a RAID
array from them and then serve it *back* to the blades as aggregated
RAID5 disk via NFS on a 2nd adapter.

Now. This *is* all now working with nbd (and, no, I am not running nbd
and enbd at the same time - one or the other).

And it *did* all work (for a time - before the time skew issue) on the
*other* machine that was acting as a client (FC4+2.6.9).

I can't now go back to that setup - I need to work on the setup that
will (now - since we last had it "working" - apart from clock skew), be
used for real (moving goalposts I'm afraid).

So - it's FC2 + 2.6.5 + 14 enbd-clients

Connecting to 14 enbd-server processes on 14 other machines.

> 
> 
> > Works perfectly with regular nbd still.
> 
> That rather indicates that you are doing something fundamentally wrong
> for enbd. Maybe using the same devices that you would be using for nbd?

Nope. Taking care on that. I think. Hmmm. Altho... Hmmm Wondering about
something...


If the other devices *exist* in /dev for the nbd driver (with the same
Maj/min numbers) I wonder if something *is* getting confused.

Hmmm. Don't know. Just thinking aloud there.

But other than that - no I am not confusing the device names - certainly
not when I am connecting using nbd-client.

Kind regards

Derek.