[Question] Writing random data to a large file fills it with zeros

[anooprdesai]

Hi,

I am using the following command to create a 64 GiB file with random data in it:

diskspd.exe -c64G -d900 -b1G -w100 -Zr -r512 -z -v F:\testfile008.dat

However, I see this creating a file with repeating 0s. The same command seems to fill random data into a smaller file (20MiB). Why does this happen and how can I fix this?

[dl2n]

What throughput does DISKSPD claim after running this for 900s?

Several things jump out.

1. a 1GiB write buffer is unusually large compared to normal IO sizes, and would not be what was used to fill in a 20MiB file. This may be stressing an issue lower in the stack though, if DISKSPD claims to run successfully, I would still expect data to be placed.
2. Why are you using random IO aligned on 512 byte boundaries? (-r512).
3. Doing random IO makes it conceivable that, depending how you are looking at the file to confirm/see the zeroes, that indeed not all of the file has been written. There are 1 + (64GB-1GB)/512 = 132,120,577 different choices of random IO offset. While the random number generator is uniform, if you're just looking at the first few MiB of the file and see zeroes, that would not be unusual - you are doing 1GiB IOs and if, say, your device achieved 1GiB/s throughput that is only 900 IOs (plus the default 5s warmup). There is no guarantee those 900 IOs will cover the file. In fact it would be very surprising if they did.

Normally this is where sequential IO would be used. Simply run it long enough to overwrite the entire file - in a future update we may support a mode of operation which makes it easier to deterministically write an entire file some number of times (say, 1) or issue a specific number of IOs.

I'd suggest sequential IO with a more usual buffer size, say 1MiB, queued a few IOs deep, e.g. something like this: -b1M -s -o4

[anooprdesai]

Thanks, that did make sense. Unfortunately though, I don't remember the results as they were quite a while ago.

I see why 3 may have caused such an issue, though and my guess is that's precisely what happened.

I eventually did get the files filled with data using sequential IO, but I remember that being awfully slow on the VM on which I was working, sometimes taking over 12 hours for a 64 GB file. As a workaround, I switched to generating these files on my PC and then copying them over to the target VM using robocopy. This was orders of magnitude faster.