On 1/6/14, 3:42 PM, Josef Bacik wrote: > > On 01/06/2014 04:32 PM, Eric Sandeen wrote: >> On 1/6/14, 1:58 PM, Josef Bacik wrote: >>> I was trying to reproduce something with fsx and I noticed that no matter what >>> seed I set I was getting the same file. Come to find out we are overloading >>> random() with our own custom horribleness for some unknown reason. So nuke the >>> damn thing from orbit and rely on glibc's random(). With this fix the -S option >>> actually does something with fsx. Thanks, >> Hm, old comments seem to indicate that this was done <handwave> to make random >> behave the same on different architectures (i.e. same result from same seed, >> I guess?) I . . . don't know if that is true of glibc's random(), is it? >> >> I'd like to dig into the history just a bit before we yank this, just to >> be sure. > > I think that if we need the output to match based on a predictable > random() output then we've lost already. We shouldn't be checking for > specific output (like inode numbers or sizes etc) that are dependant > on random()'s behaviour, and if we are we need to fix those tests. So > even if that is why it was put in place originally I'd say it is high > time we ripped it out and fixed up any tests that rely on this > behaviour. Thanks, Yeah, you're probably right. And the ancient xfstests history seems to be lost in the mists of time, at least as far as I can see. So I'm ok with this but let's let Dave & SGI chime in too just to be certain. Thanks, -Eric > Josef _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
