Re: [Qemu-devel] [PATCH] docs: clarify that qcow2 file size is not always a cluster multiple

[Stefan Hajnoczi]

On Mon, May 26, 2014 at 04:36:15PM +0200, Benoît Canet wrote:
> The Thursday 22 May 2014 à 11:42:50 (+0200), Stefan Hajnoczi wrote :
> > Normally one would expect that qcow2 image file lengths are multiples of
> > the cluster size.  This is not true in all cases and the spec should
> > document this so implementers remember to accept such files.
> > 
> > $ qemu-img create -f qcow2 foo.qcow2 2G
> > Formatting 'foo.qcow2', fmt=qcow2 size=2147483648 encryption=off 
> > cluster_size=65536 lazy_refcounts=off
> > $ ls -l foo.qcow2
> > -rw-r--r-- 1 stefanha stefanha 197120 May 22 11:40 foo.qcow2
> > $ bc -q
> > 3 * (64 * 1024) + 512
> > 197120
> > 
> > The extra sector are the 4 L1 table entries that a 2 GB disk with 64 KB
> > cluster size needs.  The rest of the L1 table is omitted from the file
> > but allocation will continue at the next cluster boundary.
> 
> I think we should fix this to allocate a whole extra cluster instead
> of 512B.
> These days most SSD pages (smalled write unit) are 4KB or 16KB.
> Having most of the file shifted by 512B mean that the SSD controller
> will have to to Read/Modify/Write cycles for most write hence impacting
> performance and SSD life.

It's not shifted.  I thought the last sentence explains this:
"The rest of the L1 table is omitted from the file but allocation will
continue at the next cluster boundary."

Are you worried that the host file system will lay out data poorly
because the file looks like this?

| header (1C) | refcounts (2C) | L1 (512B) | hole | Next cluster |

B = bytes
C = clusters

My guess is the next cluster will be aligned to a reasonable boundary on
the physical disk.

Stefan