Are the 3 serialize changes (pull requests 343/345/359) controversial or not complete? I hit the same issue in April with a similar workload:
# fio --name=DI_Stress --ioengine=libaio --direct=1 --rw=randwrite --norandommap --randrepeat=0 --iodepth=16 --size=100% --numjobs=1 --bs=2048k --filename=/dev/nvme1n1 --output=DI_Stress --verify=crc32c-intel --verify_fatal=1 --verify_dump=1 --verify_backlog=32768
I tried again now with fio 2.99 and reproduced after a few minutes:
verify: bad header numberio 4531, wanted 4532 at file /dev/nvme1n1 offset 2643506233344, length 2097152
hdr_fail data dumped as nvme1n1.2643506233344.hdr_fail
So any large block random write seems to be at risk (larger the block, higher the risk). If there are other parameters I should be setting to avoid the issue, please let me know. Thanks.
Regards,
Jeff
-----Original Message-----
From: fio-owner@xxxxxxxxxxxxxxx [mailto:fio-owner@xxxxxxxxxxxxxxx] On Behalf Of Jens Axboe
Sent: Monday, August 7, 2017 12:47 PM
To: Sitsofe Wheeler <sitsofe@xxxxxxxxx>
Cc: fio@xxxxxxxxxxxxxxx; Rebecca Cran <rebecca@xxxxxxxxxxxx>; Tomohiro Kusumi <tkusumi@xxxxxxxxxx>
Subject: Re: Pending fio 3.0 release
On 08/07/2017 01:05 PM, Sitsofe Wheeler wrote:
> Hi Jens,
>
> On 7 August 2017 at 17:10, Jens Axboe <axboe@xxxxxxxxx> wrote:
>>
>> CC'ing a few key people here - I want to release fio 3.0 shortly,
>> which is why the last released jumped to 2.99. However, before doing
>> so, I'd like to ensure that we are uptodate on platforms. Rebecca, is
>> Windows currently building fine with current -git? I suspect it is,
>> but would be nice to know for sure.
>>
>> Any other important pending fixes that should go in before 3.0 is
>> released?
>
> There are a few pull requests queued up over on
> https://github.com/axboe/fio/pulls (json+ patches, inflight overlap
> use after free fix, C++ ioengine changes, serialise overlap changes,
> sheepdog ioengine, change some output to debugging only etc.).
Just pulled that in, it's fine now that the more controversial bits are out.
> Locally, I have an experimental libiscsi ioengine, support for
> verify_state when verifying a readwrite workload, some HOWTO
> reordering to improve the man page conversion and some initial
> investigations into invalidation on Windows. The only one I'd have
> loved to see go in is the libiscsi engine but it's kinda raw and needs
> fixing up and I don't know when I'll have time to finish it...
For new engines, I don't mind merging them early, as long as the people behind them are motivated to bring them up to snuff. Up to you.
verify_state support for read/write sounds like something that would be nice to have, but isn't a must for 3.0.
Anyway, I'll likely cut 3.0 next week, so there's still time for whatever changes we need. But they have to be low risk at this point, I'd hate to do a 3.0 that broke anything recent.
> With regard to Windows, it seems to at least be building
> (https://ci.appveyor.com/project/axboe/fio/build/1.0.245 ) and running
> basic workloads for me...
Ah yes, thanks!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
��.n��������+%������w��{.n�������^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
