Re: Re: Client timeout - renegotiation failed - connection dead

Dear Peter,

> > It's probably a real time skew - ntpd catching up with reality at some
> > point close after boot.
> 
> Since a couple of people are having time problems, I took the opportunity
> to replace the calls to gettimeofday in time.c with calls to the
> "secret" uptime function in libproc, if available (you need libproc-dev,
> or point a libproc.so link from /usr/lib at your libproc.so.x.y.z in
> /lib).  That should use real time since boot instead of system time's
> changing idea of UTC.

Ah OK. Sounds like an interesting fix...

> This affects the client only, and requires /proc be mounted (but falls
> back to system time if it's not, and that probably will cause problems
> too on its own, grr  ...).

Alright. That should be OK in my situation, /proc always is on the
systems I work with.

> I flushed the current 2.4.33pre to the ftp server. It compiles here.
> Untested otherwise. I'll test later today.

Did you make the kinds of changes we had with the code as well? Or will
I have to do those again? Just curious.

In the meantime, for interest's sake, I tried with the native (extant)
nbd driver (not enbd), which I had *finally* at about the same time as
enbd "worked" the 1st time, managed to get the nbd-server and nbd-client
from the 2.8.4 series of that to compile for.

I hope to go back to enbd too, but interestingly, nbd worked, and has
been working without failure overnight.

I currently have a 600GB RAID device comprising 14 nbd components from
14 blade servers, that's then shared *back* to the blades via NFS to
give a network pooled disk shared by all machines. Performance is
actually *better* than a native share of a single NFS partition from the
headnode to a blade. I've yet to really stress test it of course with
multiple accesses from each of the blades and from external writes to
the RAID device through the headnode from outside the cluster, but it's
a promising start.

Once thing I did notice in the stats from /proc/mdstat was that the
apparent throughput I was getting with nbd was nearly an order of
magnitude greater than with enbd. That concerns me some. I'll need to
test that again when I have enbd up and working for sure once more.

I'll let you know how things go.

Thanks once again for all your help on this. I do appreciate that
maintaining enbd is not your full time job! :-)

Kind regards

Derek.