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

[Eric Blake]

On 09/23/2014 04:09 AM, Stefan Hajnoczi wrote:
> The blkdebug block driver is undocumented.  Documenting it is worthwhile
> since it offers powerful error injection features that are used by
> qemu-iotests test cases.
> 
> This document will make it easier for people to learn about and use
> blkdebug.
> 
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
> v2:
>  * Added GPL v2 or later license and Red Hat copyright [Eric]
>  * Expanded ini rules file explanation [Paolo]
>  * Added note that errno values depend on the host [Eric]
> 
>  docs/blkdebug.txt | 155 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 155 insertions(+)
>  create mode 100644 docs/blkdebug.txt
> 


> +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?

> +
> +  state - (optional) the engine must be in this state number in order for 
> this
> +       rule to match.  See the "State transitions" section for information
> +          on states.

and again?

> +
> +  errno - the numeric errno value to return when a request matches this rule.
> +          The errno values depend on the host since the numeric values are 
> not
> +          standarized in the POSIX specification.
> +
> +  sector - (optional) a sector number that the request must overlap in order 
> to
> +           match this rule
> +
> +  once - (optional, default "off") only execute this action on the first
> +         matching request
> +
> +  immediately - (optional, default "off") return a NULL BlockDriverAIOCB
> +             pointer and fail without an errno instead.  This exercises the
> +             code path where BlockDriverAIOCB fails and the caller's
> +                BlockDriverCompletionFunc is not invoked.

again?

> +
> +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/ ?

> +need to grep block driver source code to understand the meaning of specific
> +events.
> +
> +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'?

> +
> +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 ?

> +matches the next write_aio request and injects EIO (5).
> +
> +State transition 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.

More tab damage?

> +
> +  state - (optional) the engine must be in this state number in order for 
> this
> +       rule to match
> +
> +  new_state - transition to this state number
> +
> +Suspend and resume
> +------------------
> +Exercising code paths in block drivers may require specific ordering amongst
> +concurrent requests.  The "breakpoint" feature allows requests to be halted 
> on
> +a blkdebug event and resumed later.  This makes it possible to achieve
> +deterministic ordering when multiple requests are in flight.
> +
> +Breakpoints on blkdebug events are associated with a user-defined "tag" 
> string.
> +This tag serves as an identifier by which the request can be resumed at a 
> later
> +point.
> +
> +See the qemu-io(1) break, resume, remove_break, and wait_break commands for
> +details.
> 

Looking closer.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature