On Fri, 2007-07-13 at 00:24 +0200, Andi Kleen wrote: > On Thu, Jul 12, 2007 at 04:16:24PM -0600, Andreas Dilger wrote: > > On Jul 12, 2007 13:09 +0200, Andi Kleen wrote: > > > > "dd if=/dev/urandom bs=1k ..." than to spin in a loop getting 16-bit > > > > random numbers from bash. We would also be at the mercy of the shell > > > > being identical on the user and debugger's systems. > > > > > > With /dev/urandom you have the guarantee you'll never ever reproduce > > > it again. > > > > That is kind of the point of this testing - getting new test images for > > each user that runs "make check" or "make rpm". I'm We also save the > > generated image before e2fsck touches it so that it can be used for > > debugging if needed. > > If you seed a good pseudo RNG with the time (or even a few bytes from > /dev/urandom; although the time tends to work as well) you'll also effectively > get a new image every time. > > But the advantage is if you print out the seed the image > can be easily recreated just by re-running the fuzzer > with the same seed. No need to ship potentially huge images > around. > > You can essentially compress your whole image into a single > number this way. Firstly the filesystem is populated with files from the e2fsprogs source directory. The filesystem is also corrupted by copying blocks in the filesystem to some arbitary locations within it. from=`get_random_location $NUM_BLKS` to=`get_random_location $NUM_BLKS` dd if=$IMAGE of=$IMAGE bs=1k count=$CORRUPTION_SIZE conv=notrunc skip= $from seek=$to >> $OUT 2>&1 Then the filesystem also undergoes corruption with /dev/urandom. To be able to recreate the exact same filesystem with the seed, the filesystem would need to allocate the _same_ blocks and metadata on both the clients and the testers machine, which is obviously not possible. Thanks, Kalpak. > > -Andi - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
