[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pre-allocating key segments


Piete Brooks <[email protected]> writes:
>I wrote:
>> Not only that, but the client ought to allocate some keyspace before it
>> needs it, as I think one other cpunk suggested.
>I'd prefer to keep the number of segments "lost" if a brloop ceases.

Keep down, I guess you meant.

Regarding the local farm software:
>... if any keys were allocated to machines which failed to ask for another
>segment -- you should assume that that segment was not searched.

I agree that is the best policy -- it fails safe -- but I still think the
prefetching of some more segments would be useful.  The goal is to suck up
as many idle cycles as is practical.

>> For instance, if it has
>> four segments allocated and it's done three of them, it should fork a
>> process to begin requesting four more segments *while* it is scanning
>> the last segment, rather than waiting until after it is done and leaving
>> the machine idle until it can alloc more keys.
>That means that if it crashes, 8 segments are left unACKed :-(

And if it had grabbed 8 segments to begin with and crashed, it still
would have been 8 segments left unACKed.

Plus, it's only 8 segments unACKed if it crashes before it finished that
last segment, since it will start trying to ACK the first four segments
when it finishes the fourth -- at the same time starting on the next
four segments.

Would you see it any differently if I had said, "For instance, if it has
two segments allocated and it is halfway through the second segment, it
should request two more segments *while* it is scanning the last segment"?

Keeping in mind that it will still ACK the first bunch of segments when
it finishes them.

Version: 2.6.2


David R. Conrad, [email protected], http://www.grfn.org/~conrad
Finger [email protected] for PGP 2.6 public key; it's also on my home page
Key fingerprint =  33 12 BC 77 48 81 99 A5  D8 9C 43 16 3C 37 0B 50
Jerry Garcia, August 1, 1942 - August 9, 1995.  Requiescat in pace.