[Top] [All Lists]

Re: [PATCH] xfstests: kill lib/random.c

To: Eric Sandeen <sandeen@xxxxxxxxxx>, <linux-btrfs@xxxxxxxxxxxxxxx>, <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH] xfstests: kill lib/random.c
From: Josef Bacik <jbacik@xxxxxx>
Date: Mon, 6 Jan 2014 16:42:14 -0500
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=message-id : date : from : mime-version : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=facebook; bh=m2Vb6vYDyV9vY5KgrnrxueEEbpu3cV6JjDBm8Il3RxQ=; b=TPPGEWfVyxeWQ9JzFDLH32nlK6KTt4s+zKzmPcOMk8v09CIwucUdS+akpmFruZxtUXGz LMEoeHCqqw93FW0gXCMzhg+rL6doEk8oeZJVZsbWEvaDcgxzit7DibNbCKOpFjKwZRoD A848HXmpLTtlcn/h5M7vdEHkXF8e0xFagms=
In-reply-to: <52CB20ED.1010705@xxxxxxxxxx>
References: <1389038323-8304-1-git-send-email-jbacik@xxxxxx> <52CB20ED.1010705@xxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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,


<Prev in Thread] Current Thread [Next in Thread>