on 2020/02/20 9:35, Yang Xu wrote:
on 2020/02/19 23:20, Theodore Y. Ts'o wrote:
On Wed, Feb 19, 2020 at 01:43:24PM +0100, Jan Kara wrote:
This means, fsstress command has queued cache flush request (from
blkdev_issue_flush()), this has been dispatched to the driver ('D'
event)
but it has never been completed by the driver and so
blkdev_issue_flush()
never returns.
To debug this further, you probably need to start looking into what
happens
with the request inside QEMU. There's not much I can help you with at
this
point since I'm not an expert there. Do you use image file as a
backing store
or a raw partition?
This is looking more and more like a Qemu bug or a host OS issue.
Yang is using a two year old Qemu (qemu-kvm-2.12.0-32.el8+1900+70997154)
and is using a QCOW backing file. It also could be a host kernel bug,
although that's less likely.
Yang, any chance you could have a chance to upgrade to a newer version
of Qemu, and see if the problem goes away? If you have a RHEL support
contract, perhaps you could file a support request with the Red Hat
help desk?
Of course, I will update lastest qemu to test.(I don't have their support).
Hi Ted, Jan
I have updated lastest qemu(4.2.0), it still hangs. But I think it
is not fs problem. Because it only failed when disk uses IDE bus, I use
scsi bus, it passed. Thanks for your analysis and help.
Best Regards
Yang Xu
- Ted
