[Pvfs2-developers] handle ledger

[Sam Lang]

Here's the latest with a number of important changes:

* removed all reference to ledger code.  The current ledger files are  
still in place but never get invoked by the rest of the code.
* added a hash for recently removed handles with an expiration to  
prevent reusing handles too quickly.  This is mostly a failsafe --  
generating a handle value from a 64 bit space isn't going to collide  
with any of the recently deleted ones.
* removed all references to handles_available in statfs
* fallback to srand if urandom not supported.

-sam


-------------- next part --------------
A non-text attachment was scrubbed...
Name: noledger.patch
Type: application/octet-stream
Size: 53137 bytes
Desc: not available
Url : http://www.beowulf-underground.org/pipermail/pvfs2-developers/attachments/20080205/a42ddab7/noledger-0001.obj
-------------- next part --------------




On Jan 29, 2008, at 4:41 PM, Pete Wyckoff wrote:

> slang at mcs.anl.gov wrote on Tue, 29 Jan 2008 15:53 -0600:
>> On Jan 29, 2008, at 1:42 PM, Pete Wyckoff wrote:
>>> Yeah.  It will just run through the same set of allocated handles,
>>> taking a long time that first time for people with lousy RNGs.  Then
>>> it will fall into an unallocated space and continue normally.  As
>>> long as there is a configure test for random_r, we can fall back to
>>> lrand48() and friends or even ancient srand/rand.  /dev/urandom
>>> test must be at runtime, with graceful fallback to a seed made up of
>>> hostname[0:255] | time() << 29 | coll_id << 63 | ... any other
>>> random stuff you can get your hands on in that routine easily.
>>
>> Not sure hostname is actually useful in this case, since the  
>> handles are
>> allocated (and only need to be unique) per-server.  Same with the  
>> fs_id.  I
>> could use process id I suppose...
>>
>> Can I check for /dev/urandom with a runtime check in configure, or  
>> are
>> those verboten for cross-compiles?
>
> Verboten unfortunately.  Just cause it works on the linux front-end
> doesn't mean it will work on the catamount/bg/whatever odd back end.
> Although I think people only ever run servers on real machines these
> days.  But catching open() return values is pretty easy.
>
> 		-- Pete
>