qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] glusterfs: allow partial reads


From: Eric Blake
Subject: Re: [Qemu-devel] [RFC PATCH] glusterfs: allow partial reads
Date: Tue, 6 Dec 2016 09:02:33 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 12/06/2016 03:59 AM, Kevin Wolf wrote:

>>>> I'm not sure what the original rationale was to treat both partial
>>>> reads as well as well as writes as I/O error. (Seems to have happened
>>>> from original glusterfs v1 to v2 series with a note but no reasoning
>>>> for the read side as far as I could see.)
>>>> The general direction lately seems to be to move away from sector
>>>> based block APIs. Also eg. the NFS code allows partial reads. (It
>>>> does, however, have an old patch (c2eb918e3) dedicated to aligning
>>>> sizes to 512 byte boundaries for file creation for compatibility to
>>>> other parts of qemu like qcow2. This already happens in glusterfs,
>>>> though, but if you move a file from a different storage over to
>>>> glusterfs you may end up with a qcow2 file with eg. the L1 table in
>>>> the last 80 bytes of the file aligned to _begin_ at a 512 boundary,
>>>> but not _end_ at one.)
> 
> Hm, does this really happen? I always thought that the file size of
> qcow2 images is aligned to the cluster size. If it isn't, maybe we
> should fix that.

Yes, it absolutely happens all the time!  In fact, it is often the case
that our images are not even sector-aligned, let alone cluster-aligned:

$ qemu-img create -f qcow2 file 1M
Formatting 'file', fmt=qcow2 size=1048576 encryption=off
cluster_size=65536 lazy_refcounts=off refcount_bits=16
$ ls -l file
-rw-r--r--. 1 eblake eblake 196616 Dec  6 08:58 file
$ echo $((384*512))
196608
$ echo $((385*512))
197120

196616 is a fraction more than 384 sectors.

This is because the qcow2 format explicitly requires that if the L1 or
L2 table is at the end of the file (which is what happens by default in
qemu-img create), any entries not physically present in the table
(because the file ends early) are read as 0.

>>> Would it be better to switch to byte-based interfaces rather than
>>> continue to force gluster interaction in 512-byte sector chunks,
>>> since gluster can obviously store files that are not 512-aligned?
> 
> The gluster I/O functions are byte-based anyway, and the driver already
> implements .bdrv_co_readv, so going to .bdrv_co_preadv should be
> trivial. Probably the best solution here indeed.
> 

Are we still hoping to fix this bug (the gluster behavior on unaligned
files, not the larger [non-?]bug of qemu-img create giving unaligned
images in the first place) for 2.8, or are we pushing our luck here,
where the correct patch should be 2.9 material and cc qemu-stable?

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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