From: Andrea Arcangeli <aarcange@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Christoph Hellwig <hch@lst.de>
Subject: [Qemu-devel] [PATCH] ide: cleanup warnings
Date: Tue, 3 May 2011 22:03:39 +0200 [thread overview]
Message-ID: <20110503200339.GA7838@random.random> (raw)
Hello,
This is just a minor cleanup adding \n.
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).
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.
Maybe we can deal with iscsi server going down in a safer way by
retrying in the host (transparently to the guest and unnoticed to the
local fs in the guest) with virtio-blk as we have full control the
guest driver (we don't control the guest ide driver instead)? OTOH
that may lead to indefinite guest I/O hangs which may not be nice for
the guest either if iscsi never returns up (though it would diminish
the chance of triggering guest fs bugs in not well tested I/O error
paths).
===
Subject: ide: cleanup warnings
From: Andrea Arcangeli <aarcange@redhat.com>
Add \n.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---
hw/ide/pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/hw/ide/pci.c
+++ b/hw/ide/pci.c
@@ -298,9 +298,9 @@ void bmdma_cmd_writeb(void *opaque, uint
qemu_aio_flush();
#ifdef DEBUG_IDE
if (bm->bus->dma->aiocb)
- printf("ide_dma_cancel: aiocb still pending");
+ printf("ide_dma_cancel: aiocb still pending\n");
if (bm->status & BM_STATUS_DMAING)
- printf("ide_dma_cancel: BM_STATUS_DMAING still pending");
+ printf("ide_dma_cancel: BM_STATUS_DMAING still pending\n");
#endif
}
} else {
next reply other threads:[~2011-05-03 20:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 20:03 Andrea Arcangeli [this message]
2011-05-04 8:08 ` [Qemu-devel] [PATCH] ide: cleanup warnings Kevin Wolf
2011-05-04 13:41 ` Andrea Arcangeli
2011-05-04 13:57 ` Kevin Wolf
2011-05-04 14:04 ` Andrea Arcangeli
2011-05-04 14:15 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110503200339.GA7838@random.random \
--to=aarcange@redhat.com \
--cc=hch@lst.de \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).