From: Peter Lieven <pl@kamp.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com, jcody@redhat.com, jsnow@redhat.com,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH V2 0/4] ide: avoid main-loop hang on CDROM/NFS failure
Date: Mon, 26 Oct 2015 11:56:26 +0100 [thread overview]
Message-ID: <562E06DA.3070902@kamp.de> (raw)
In-Reply-To: <20151026104252.GB20111@stefanha-x1.localdomain>
Am 26.10.2015 um 11:42 schrieb Stefan Hajnoczi:
> On Mon, Oct 12, 2015 at 02:27:21PM +0200, Peter Lieven wrote:
>> This series aims at avoiding a hanging main-loop if a vserver has a
>> CDROM image mounted from a NFS share and that NFS share goes down.
>> Typical situation is that users mount an CDROM ISO to install something
>> and then forget to eject that CDROM afterwards.
>> As a consequence this mounted CD is able to bring down the
>> whole vserver if the backend NFS share is unreachable. This is bad
>> especially if the CDROM itself is not needed anymore at this point.
>>
>> This series aims at fixing 2 blocking I/O operations that would
>> hang if the NFS server is unavailable:
>> - ATAPI PIO read requests used sync calls to blk_read, convert
>> them to an async variant where possible.
>> - If a busmaster DMA request is cancelled all requests are drained.
>> Convert the drain to an async request canceling.
>>
>> v1->v2: - fix offset for 2352 byte sector size [Kevin]
>> - use a sync request if we continue an elementary transfer.
>> As John pointed out we enter a race condition between next
>> IDE command and async transfer otherwise. This is sill not
>> optimal, but it fixes the NFS down problems for all cases where
>> the NFS server goes down while there is no PIO CD activity.
>> Of course, it could still happen during a PIO transfer, but I
>> expect this to be the unlikelier case.
>> I spent some effort trying to read more sectors at once and
>> avoiding continuation of elementary transfers, but with
>> whatever I came up it was destroying migration between different
>> Qemu versions. I have a quite hackish patch that works and
>> should survive migration, but I am not happy with it. So I
>> would like to start with this version as it is a big improvement
>> already.
>> - Dropped Patch 5 because it is upstream meanwhile.
>>
>> Peter Lieven (4):
>> ide/atapi: make PIO read requests async
>> ide/atapi: blk_aio_readv may return NULL
>> ide: add support for cancelable read requests
>> ide/atapi: enable cancelable requests
>>
>> hw/ide/atapi.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++------
>> hw/ide/core.c | 55 +++++++++++++++++++++++++++++++
>> hw/ide/internal.h | 16 +++++++++
>> hw/ide/pci.c | 42 +++++++++++++++--------
>> 4 files changed, 188 insertions(+), 24 deletions(-)
> Any reason why write and discard requests aren't covered in this series?
>
> If this is a good idea for CD-ROM it should be a good idea for all PCI
> IDE devices.
>
> Having a specialized code path is often a sign that it hasn't been
> tested enough. Can we get confident enough to enable this everywhere?
The reason is that the buffered request trick does only work for
read-only devices (like a CDROM). A write request that is completed
on the backend storage at a later point (after the OS thinks the request
is canceled) can cause damage to the filesystem.
Peter
next prev parent reply other threads:[~2015-10-26 10:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 12:27 [Qemu-devel] [PATCH V2 0/4] ide: avoid main-loop hang on CDROM/NFS failure Peter Lieven
2015-10-12 12:27 ` [Qemu-devel] [PATCH 1/4] ide/atapi: make PIO read requests async Peter Lieven
2015-10-22 16:17 ` Stefan Hajnoczi
2015-10-23 15:17 ` Peter Lieven
2015-11-03 0:48 ` John Snow
2015-11-03 7:03 ` Peter Lieven
2015-10-12 12:27 ` [Qemu-devel] [PATCH 2/4] ide/atapi: blk_aio_readv may return NULL Peter Lieven
2015-10-22 16:20 ` Stefan Hajnoczi
2015-10-23 15:18 ` Peter Lieven
2015-10-12 12:27 ` [Qemu-devel] [PATCH 3/4] ide: add support for cancelable read requests Peter Lieven
2015-10-26 10:39 ` Stefan Hajnoczi
2015-10-27 10:58 ` Peter Lieven
2015-10-28 11:26 ` Stefan Hajnoczi
2015-10-28 19:56 ` Peter Lieven
2015-10-12 12:27 ` [Qemu-devel] [PATCH 4/4] ide/atapi: enable cancelable requests Peter Lieven
2015-10-26 10:42 ` [Qemu-devel] [PATCH V2 0/4] ide: avoid main-loop hang on CDROM/NFS failure Stefan Hajnoczi
2015-10-26 10:56 ` Peter Lieven [this message]
2015-10-28 11:27 ` Stefan Hajnoczi
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=562E06DA.3070902@kamp.de \
--to=pl@kamp.de \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--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.