Re: fixup_slot failed to find slot....
scunacc <[email protected]> Fri, 10 Mar 2006 02:07:55 -0500
| Newsgroups | gmane.linux.enbd.general |
|---|---|
| Message-ID | <1141974476.6630.51.camel@scuna-gate> |
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.