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
|