qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/6] null: Switch to byte-based read/write


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 3/6] null: Switch to byte-based read/write
Date: Tue, 24 Apr 2018 19:19:20 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 24.04.2018 um 19:00 hat Eric Blake geschrieben:
> On 04/24/2018 10:52 AM, Kevin Wolf wrote:
> > Am 15.02.2018 um 20:28 hat Eric Blake geschrieben:
> >> We are gradually moving away from sector-based interfaces, towards
> >> byte-based.  Make the change for the last few sector-based callbacks
> >> in the null-co and null-aio drivers.
> >>
> >> Note that since the null driver does nothing on writes, it trivially
> >> supports the BDRV_REQ_FUA flag (all writes have already landed to
> >> the same bit-bucket without needing an extra flush call).  Furthermore,
> >> bdrv_refresh_limits() defaults the block size to 512 for any driver
> >> that does not support coroutines; while this is still correct for the
> >> other aio-based drivers, the null driver does just as well with
> >> byte-based requests, and being explicit means we can avoid cycles
> >> wasted on read-modify-write.
> >>
> >> Signed-off-by: Eric Blake <address@hidden>
> > 
> >> +static void null_refresh_limits(BlockDriverState *bs, Error **errp)
> >> +{
> >> +    bs->bl.request_alignment = 1;
> >> +}
> > 
> > I would rather modify bdrv_refresh_limits() so that it defaults to 1 for
> > drivers supporting either .bdrv_co_preadv or .bdrv_aio_preadv.
> 
> Sure, I can do that (although then I may have to provide a
> refresh_limits callback for each of the other drivers that I
> specifically left at 512 alignment).

Do we know that the other drivers need 512, or do we expect than they
can handle byte granularity, but we try to err on the safe side?

If it's the latter (which would be my expectation), then it's probably
better to set request_alignment = 512 with a comment in those drivers
and hope that someone will lift the restriction in the future.

Kevin

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]