Il 28/05/2013 11:18, Kevin Wolf ha scritto: >>> The other part why I haven't sent a fix yet is that I don't have a test >>> case for it. >> >> Temporarily add a sleep(31) in qemu_fdatasync()? >> >> I was lazy in testing with -snapshot to not corrupt my disk image, which >> would not trigger the same issue since qcow2-backed AFAIU. >> >>> I guess I need to extend blkdebug first before this can be >>> reliably tested by qtest. >> >> It can't, since it's not a pure device emulation issue but depends on >> the relative timing of filesystem operations and subsequent commands. > > That's why you need to take influence on the timing. It's no excuse for > merging without a test case. If we only ever tested devices that have no > relation to the outside world, our testing would be pretty useless and > always stay as bad as it is today in many areas.
I don't think the qtest would be timing dependent. The Linux testcase is timing dependent, but for the qtest all you need to check is "is BUSY set during a flush?". This can be done with blkdebug suspend/resume, except that there is no way to call bdrv_debug_resume from QEMU. Paolo
