2006-05-01 20:10:30

by Circuitsoft Development

[permalink] [raw]
Subject: Fwd: Extended Volume Manager API

On 5/1/06, [email protected] <[email protected]> wrote:
> On Mon, 01 May 2006 00:26:05 CDT, Circuitsoft Development said:
> > about 600 microseconds, topped at 3msec over 10 minutes) I figure that
> > 5msec timeout won't add any noticeable lag to the volume manager, as
> > most disk seek times are in that range.
>
> Note that if you're setting 5ms as your timeout for detecting a *crash*,
> and your *ping* takes 3ms, that leaves you a whole whopping 2ms. If you
> have 1ms scheduler latency at *each* end (remember - you're in userspace

Volume/Lock manager in Kernelspace - Don't feel like dealing with
user-mode block devices

I was actually planning on a 5msec timeout to ignore that computer,
for now, then if I don't get a response within 100msec, ping them,
and permenantly remove them from the list of peers and broadcast a
"this peer is dead" message to the network if the ping times out at
500msec.

> at both ends, right?) you have approximately 0ms left for the remote end to
> actually *do* anything, and for the local end to process the reply.
>
> And if the remote end has to issue a syscall during processing the request,
> you're basically screwed.

The code on the remote end is checking a list of locks to see if a
block is in it.


2006-05-05 19:03:40

by Rik van Riel

[permalink] [raw]
Subject: Re: Fwd: Extended Volume Manager API

On Mon, 1 May 2006, Circuitsoft Development wrote:

> I was actually planning on a 5msec timeout to ignore that computer,
> for now, then if I don't get a response within 100msec, ping them,
> and permenantly remove them from the list of peers and broadcast a
> "this peer is dead" message to the network if the ping times out at
> 500msec.

How are you going to prevent your "dead" peer from writing
to the disk anyway ?

--
All Rights Reversed