axboe / fio

Flexible I/O Tester
GNU General Public License v2.0
5.23k stars 1.26k forks source link

Accept percent value for offset parameter #362

Open cbwest3 opened 7 years ago

cbwest3 commented 7 years ago

Similar to how the size parameter accepts a percent value, allow offset to accept a percent value. This would allow for uniform workloads across raw devices, regardless of the device's size.

sitsofe commented 7 years ago

This is a duplicate of #89 ...

cbwest3 commented 7 years ago

True, I should have dug further, thanks.

sitsofe commented 7 years ago

This has been fixed by https://github.com/axboe/fio/commit/2293bf6886095fc180a77a958511bd6385840874 ...

sitsofe commented 7 years ago

Hang on, something doesn't seem right:

$ rm /tmp/fiofile; ./fio --stonewall --filename=/tmp/fiofile --rw=write     --name=secondhalf  --size=48k --offset=50% --buffer_pattern=0x33
secondhalf: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-2.20-36-g2293
Starting 1 process
secondhalf: Laying out IO file (1 file / 0MiB)
[...]
$ hexdump -C /tmp/fiofile 
00000000  33 33 33 33 33 33 33 33  33 33 33 33 33 33 33 33  |3333333333333333|
*
0000c000

@cbwest3 Shouldn't there be a gap at the beginning of /tmp/fiofile?

axboe commented 7 years ago

The initial fill will use the buffer pattern too. Fill it with zero first, if you just want to verify that the actual job does what it should:

$ dd if=/dev/zero of=fiofile bs=1k count=48 $ ./fio --stonewall --filename=fiofile --rw=write --name=thirdquarter --offset=50% --buffer_pattern=0x33 $ hexdump fiofile 0000000 0000 0000 0000 0000 0000 0000 0000 0000 0006000 3333 3333 3333 3333 3333 3333 3333 3333 000c000

sitsofe commented 7 years ago

@axboe Actually I think it's a misunderstanding on my part: because the file didn't exist offset was actually 0% and size was 48Kbytes thus I ended up with a file which was 48Kbytes big with just 0x33 inside. Perhaps it needs to be an error to use a percentage offset without a pre-existing file (in a similar way that size complains if the file doesn't already exist)?

axboe commented 7 years ago

If the file doesn't exist, then 'size' must be given. If the file does exist, then we should use that size, unless 'size' is given. If 'size' is given it should always take preference. Only if 'size' isn't given and the file exists, should we use that size.

That's how offset should work. Whatever size we work out from the above, 'offset' (as a percentage or otherwise) should apply to that.

sitsofe commented 7 years ago

@axboe The problem is size means two things:

  1. The size to make the file.
  2. The end-point to do I/O within.

Issues arise from the conflation of the above. If the file doesn't exist and I ask for size=1M offset=25% did I mean a) File size is 1MByte do I/O from 256K-1024K or b) Do I/O from 256K-1280K by making a file 1.25MBytes big ?

Further, if I as a user were to see either a) or b) behaviour when there isn't a file I might reasonably expect the same behaviour when the file does exist (offset to be relative to the explicitly passed in size). However always making offset percentage relative always relative to an explicitly passed in size makes things like size=0 offset=25%, size=25% offset=25% etc. give undesirable behaviour on a pre-existing file...

Surely it's less confusing and simpler to limit offset percentages to only work if the file pre-exists in a similar fashion that size percentage does?

axboe commented 7 years ago

Yes, percentages can only work if the size is already known. Outside of that, it makes no sense, and it would be best to just disallow that combo.