Re: [Qemu-devel] [PATCH v2] docs: add blkdebug block driver documentation

[Stefan Hajnoczi]

On Tue, Sep 23, 2014 at 11:12:52AM -0600, Eric Blake wrote:
> On 09/23/2014 04:09 AM, Stefan Hajnoczi wrote:
> > +Rules support the following attributes:
> > +
> > +  event - which type of operation to match (e.g. read_aio, write_aio,
> > +     flush_to_os, flush_to_disk).  See the "Events" section for
> > +          information on events.
> 
> TAB vs space damage?

Yes, thanks for spotting it.  Fixed in v3.

> > +Events
> > +------
> > +Block drivers provide information about the type of I/O request they are 
> > about
> > +to make so rules can match specific types of requests.  For example, the 
> > qcow2
> > +block driver tells blkdebug when it accesses the L1 table so rules can 
> > match
> > +only L1 table accesses and not other metadata or guest data requests.
> > +
> > +The core events are:
> > +
> > +  read_aio - guest data read
> > +
> > +  write_aio - guest data write
> > +
> > +  flush_to_os - write out unwritten block driver state (e.g. cached 
> > metadata)
> > +
> > +  flush_to_disk - flush the host block device's disk cache
> > +
> > +See block/blkdebug.c:event_names[] for the list of available events.  You 
> > may
> 
> s/available events/additional available events/ ?

I'll say "for the full list of events" since event_names[] includes
everything.

> > +State transitions
> > +-----------------
> > +There are cases where more power is needed to match a particular I/O 
> > request in
> > +a longer sequence of requests.  For example:
> > +
> > +  write_aio
> > +  flush_to_disk
> > +  write_aio
> > +
> > +How do we match the 2nd write_aio but not the first?  This is where state
> > +transitions come in.
> > +
> > +The error injection engine has an integer called the "state" that always 
> > starts
> > +initialized to 1.  Rules can be conditional on the state and they can
> > +transition to a new state.
> 
> Is the current state of the engine in a running guest introspectible,
> such as through 'query-block'?

No.

> > +
> > +For example, to match the 2nd write_aio:
> > +
> > +  [set-state]
> > +  event = "write_aio"
> > +  state = "1"
> > +  new_state = "2"
> > +
> > +  [inject-error]
> > +  event = "write_aio"
> > +  state = "2"
> > +  errno = "5"
> > +
> > +The first write_aio request matches the set-state rule and transitions from
> > +state 0 to state 1.  Once state 1 has been entered, the set-state rule no
> > +longer matches since it required state 0.  But the inject-error rule now
> 
> state 0/1 or state 1/2 ?

Thanks for catching this, I should explain the difference between state
0 and 1.

This was a mistake because I original used "0" but it actually has to be
"1".

pgpolc8U_CO_B.pgp
Description: PGP signature