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


Attachment: noledger.patch
Description: Binary data





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

[EMAIL PROTECTED] 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


_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to