On Wed, 02/08 11:00, Adrian Suarez wrote:
> >
> > Do you only start submitting request to B (step 3) after the fast device
> > I/O
> > completes (step 2.a)? The fact that they are serialized incurs extra
> > latency.
> > Have you tried to do 2 and 3 in parallel with AIO?
>
>
> In step 2, we perfo
>
> Do you only start submitting request to B (step 3) after the fast device
> I/O
> completes (step 2.a)? The fact that they are serialized incurs extra
> latency.
> Have you tried to do 2 and 3 in parallel with AIO?
In step 2, we perform an asynchronous call to the fast device, supplying a
call
On Wed, 02/08 14:59, Max Reitz wrote:
> CC-ing qemu-block, Stefan, Fam.
>
>
> On 08.02.2017 03:38, Adrian Suarez wrote:
> > We’ve implemented a block driver that exposes storage to QEMU VMs. Our
> > block driver (O) is interposing on writes to some other type of storage
> > (B). O performs low la
CC-ing qemu-block, Stefan, Fam.
On 08.02.2017 03:38, Adrian Suarez wrote:
> We’ve implemented a block driver that exposes storage to QEMU VMs. Our
> block driver (O) is interposing on writes to some other type of storage
> (B). O performs low latency replication and then asynchronously issues the
We’ve implemented a block driver that exposes storage to QEMU VMs. Our
block driver (O) is interposing on writes to some other type of storage
(B). O performs low latency replication and then asynchronously issues the
write to the backing block driver, B, using bdrv_aio_writev(). Our problem
is tha
