qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]