[RC5] LIFO? Is this true?

James Mastros root at jennifer-unix.dyn.ml.org
Tue May 12 16:23:32 EDT 1998


On Mon, 11 May 1998 gindrup at okway.okstate.edu wrote:
>      Locking entire shared files is a terrible idea.  This locking 
>      technique locks the entire buff-in down during a fetch or during a 
>      "get a new block to crack".  Locking the entire file defeats the 
>      advantage of multithreading the clients.  All clients that finish a 
>      block during a fetch have to wait until the fetch is completed to 
>      get a new block *even if the block they get isn't a newly fetched 
>      one*.
Well, during the network IO stage of the fetch, you wouldn't need to hold
any lock on the file, and that is the slow part.  But yes, locks are
generaly bad when not needed.

>      Clients "should" do record-level locking.  
[snip = but MS OSes can't without help]
>      Finally, a FIFO buff-* file doesn't require any data structure.  
... Except a two-bit-per-block lock array (one bit for read, one for
write.  I don't think we ever need to block one and not the other, but
just in case it isn't much extra space).

>      No 
>      header is required because the number of blocks in the file can be 
>      inferred directly from the file size.  
Though a magic would be nice anyway, else you could accedently flush a
buff-in or crack a buff-out -- or at least attempt to more easyly.

>      requires more time than not having to verify it.  At the time this 
>      architectural decision was made, time was better spent on other 
>      endeavours.  Expecting that the v2 clients will change now that the 
>      v2 specification is so well tested is folly.  v3 has been touted to 
>      be FIFO (for RC5-64 and DES-x-y) (and there's some mild question as 
>      to whether or not it will support LIFO, since I can imagine the v3 
>      distributed filesystem working as named pipes instead of inert 
>      storage, an implementation that would necessitate FIFO and make LIFO 
>      require additional client code).
This is not acatually a question of the over-the-wire spec, but the
on-disk spec.  I can't see any possible spec for DES or RC5 that could
specificly prohibit either LIFO or LILO.  In any case, it has been stated
that d.net's clients that speak v3 will use LILO buffering.  
(If you ask me, this whole project needs a little more Bazaarity (as in
_The Cathedral and The_). We have plenty of weirdness, though.  <G>)

	-=- James Mastros
-- 
"True mastery is knowing enough to bullshit the rest."
	-=- Me
--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list