Execution time longer than the parameter execution time on WSL Ubuntu

[PierreAntoineAP]

I run this command on WSL Ubuntu : ./DISKSPD/amd64/diskspd.exe -d10 -W5 -C0 -c5G -t1 -o2 -b64K -fs -L -r -Rxml -Sh -w0 ./disk-speed-test.dat > ./9f4cb834-6ded-45e0-96f7-976910404281.xml So the execution time should be 15 seconds, counting the 5-second warmup and 10-second duration. But the actual execution time is 1 minute.

[dl2n]

Do you see the -d10 10s duration reflected in the output, or is it actually running for a longer period of time? Do you see IO for the entire minute, and is it constant or does it vary? (how much of the interval appears to be qd2 64k reads v. something else?)

-c5G creates a new file at the named location. When this happens, DISKSPD does one of two things to push valid data length Win32 SetFileValidData to the end of the new file: either SetFileValidData itself, requiring privileges described there, or it will write the file through once. All of this is before the warmup/measured duration/cooldown.

Do you see warning from DISKSPD about using a "slower" method to prepare the file (see code here), and is there any IOPS/BW constraint on the WSL environment and/or Ubuntu hosting environment that might make the slow method (5G of writes) take about 45s?

[PierreAntoineAP]

For a duration of 10 seconds I see in the output that it lasts more than 1 minute and the IO are present throughout the minute constantly. Yes, I've run two warnings: WARNING: Error adjusting token privileges for SeManageVolumePrivilege (error code: 1300) WARNING: Could not set privileges for setting valid file size; will use a slower method of preparing the file.

[dl2n]

OK, so that's exactly what's happening. There is certainly (always) a longer description to attach to it (see above), but DISKSPD when run w/o privilege to assert SeManageVolumePrivilege cannot invoke SetFileValidData and therefore has to write the entire file through to get it into its standard if-created-by-DISKSPD state: with valid data at the end of the file.

The good news is that one form of the right thing is happening for you, automatically.

If you are creating the file each time in a multi-invocation run, though (-c5G), you can avoid this overhead by creating the file once with a throwaway (or simply "preparation") load that runs for a brief time and leaves the file in a known state. Then reuse the file as many times as you like.

[PierreAntoineAP]

Well, thank you for your help Dan.