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
