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

[Benoît Canet]

The Tuesday 27 May 2014 à 15:24:00 (+0200), Stefan Hajnoczi wrote :
> 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.

I have some kind of doubt. Does anyone knows a filesystem guru ?

> 
> Stefan