From: Hannes Reinecke <hare@suse.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Alexander Graf <agraf@suse.de>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: [Qemu-devel] virtio-scsi and error handling
Date: Tue, 11 Jun 2013 13:41:38 +0200 [thread overview]
Message-ID: <51B70CF2.1020306@suse.de> (raw)
Hi Stefan,
I currently playing around with improving SCSI EH, optimizing
command aborts and the like.
And, supposing it to be a nice testbed, tried to make things work
with virtio_scsi.
However, looking at the code there I've found virtscsi_tmf() just
uses 'wait_for_completion', with no timeout specified. So in effect
any abort might stall forever.
Wouldn't it be more sensible to use 'wait_for_completion_timeout'
here, to allow the error escalation to continue?
This would especially be useful when running with multipathing,
as the underlying device might stall, and aio_cancel() doesn't work
reliably, if at all.
Also I've found that there is no host reset. Currently the virtio
semantics seem to require reliable communication, ie for every
command send there _has_ to be a response.
Long and painful experience with RAID HBAs has shown that this model
works okay for the lower-level escalations, but you absolutely need
a host reset to restore communication.
In the case of virtio I would think that a virtio-level reset for
host_reset would be a sensible idea.
Any opinions from your side?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
next reply other threads:[~2013-06-11 11:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-11 11:41 Hannes Reinecke [this message]
2013-06-12 7:56 ` [Qemu-devel] virtio-scsi and error handling Stefan Hajnoczi
2013-06-12 20:19 ` Paolo Bonzini
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=51B70CF2.1020306@suse.de \
--to=hare@suse.de \
--cc=agraf@suse.de \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.