From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Tony Asleson <tasleson@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [RFC 0/4] POC: Generating realistic block errors
Date: Thu, 21 Nov 2019 12:12:55 +0100 [thread overview]
Message-ID: <20191121111255.GC6007@linux.fritz.box> (raw)
In-Reply-To: <20191121103012.GE439743@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
Am 21.11.2019 um 11:30 hat Stefan Hajnoczi geschrieben:
> On Thu, Nov 14, 2019 at 09:47:48AM -0600, Tony Asleson wrote:
> > On 9/20/19 12:28 PM, Tony Asleson wrote:
> > > On 9/20/19 4:22 AM, Stefan Hajnoczi wrote:
> > >> blkdebug is purely at the QEMU block layer level. It is not aware of
> > >> storage controller-specific error information or features. If you want
> > >> to inject NVMe- or SCSI-specific errors that make no sense in QEMU's
> > >> block layer, then trying to do it in blkdebug becomes a layering
> > >> violation. This justifies adding a new error injection feature directly
> > >> into AHCI, virtio-scsi, NVMe, etc devices.
> > >
> > > Good discussion point...
> > >
> > > In my opening use case for this POC I'm generically trying to create an
> > > unrecoverable media error for a specific sector. For each of the
> > > different device types it's different on how that error is conveyed and
> > > the associated data in transfer.
> > >
> >
> > I would like to get some additional clarification on this point. Should
> > I be investing more time integrating my proposed functionality into
> > blkdebug or other?
> >
> > Sorry for the long response time, got sidetracked with other stuff.
>
> blkdebug can inject EIO when a specific LBA is accessed. Is that
> enough for what you want to do? Then you can reuse and maybe extend
> blkdebug.
And if we need something more device specific, maybe a common core can
be extracted that can be used by both blkdebug and the devices. All of
the logic of managing error injection rules and checking whether
something needs to be done at the current event should be common between
both.
Kevin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2019-11-21 11:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 19:48 [RFC 0/4] POC: Generating realistic block errors Tony Asleson
2019-09-19 19:48 ` [RFC 1/4] Add qapi for block error injection Tony Asleson
2019-09-20 9:03 ` Philippe Mathieu-Daudé
2019-09-20 15:17 ` Tony Asleson
2019-09-19 19:48 ` [RFC 2/4] SCSI media error reporting Tony Asleson
2019-09-19 19:48 ` [RFC 3/4] NVMe " Tony Asleson
2019-09-19 19:48 ` [RFC 4/4] ahci " Tony Asleson
2019-09-19 20:43 ` John Snow
2019-09-19 21:49 ` Tony Asleson
2019-09-20 17:22 ` John Snow
2019-09-20 8:43 ` Kevin Wolf
2019-09-20 16:18 ` John Snow
2019-09-20 19:25 ` Tony Asleson
2019-09-20 19:29 ` John Snow
2019-09-20 8:36 ` [RFC 0/4] POC: Generating realistic block errors Kevin Wolf
2019-09-20 16:41 ` Tony Asleson
2019-09-20 17:08 ` Eric Blake
2019-09-20 19:15 ` Tony Asleson
2019-09-20 18:11 ` Kevin Wolf
2019-09-20 18:55 ` Tony Asleson
2019-09-30 14:54 ` Kevin Wolf
2019-09-20 9:22 ` Stefan Hajnoczi
2019-09-20 17:28 ` Tony Asleson
2019-11-14 15:47 ` Tony Asleson
2019-11-21 10:30 ` Stefan Hajnoczi
2019-11-21 11:12 ` Kevin Wolf [this message]
2019-11-26 18:19 ` Tony Asleson
2019-11-26 19:28 ` Kevin Wolf
2019-09-20 9:25 ` Stefan Hajnoczi
2019-09-20 14:41 ` no-reply
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=20191121111255.GC6007@linux.fritz.box \
--to=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=tasleson@redhat.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 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).