Am 06.12.2016 um 16:02 hat Eric Blake geschrieben: > 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?
I think we're too late for 2.8. Kevin
pgpUuN4Y8ownI.pgp
Description: PGP signature