[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] ide: cleanup warnings
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] ide: cleanup warnings |
Date: |
Wed, 04 May 2011 10:08:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 |
Am 03.05.2011 22:03, schrieb Andrea Arcangeli:
> Hello,
>
> This is just a minor cleanup adding \n.
Thanks, applied to the block branch.
> On a side note, it was good idea to keep it under DEBUG_IDE because if
> iscsi server reboots or goes down, this would generate a flood of
> errors if it's enabled (a flood of these warnings would have been
> shown with DEBUG_IDE on in such a condition).
Isn't it a bug that qemu_aio_flush() doesn't clear aiocb/status? Should
we move the ide_set_inactive() call from ide_dma_error to ide_dma_cb?
> So I've also been wondering if it's safe to ignore these warnings when
> the iscsi server is down. The error is delivered up to ide which
> simulates a I/O error for the guest (something like
> BM_STATUS_PIO_RETRY), so then it should be up to the guest OS to retry
> long enough and deal with it without corrupting the guest filesystem
> image. Often local filesystems in the guest (ext4/brfs/xfs etc...)
> won't be heavily tested for I/O errors. So it would be somewhat safer
> to retry on the qemu side without passing errors up to the guest, OTOH
> the guest ide driver might eventually notice a DMA timeout if the I/O
> doesn't complete in a timely fashion, so retrying indefinitely in qemu
> aio layer wouldn't be a definitive solution to avoid triggering guest
> os bugs... So in the end this is probably the best way we can handle
> the iscsi server disconnect with ide.
This is actually something controlled by werror. With werror=stop, the
VM is stopped and the guest never sees the error, but qemu retries. With
werror=report, the error is reported to the guest which can retry.
Kevin