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,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
