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
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. Icould use process id I suppose...Can I check for /dev/urandom with a runtime check in configure, or arethose 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
