Re: [Qemu-devel] disk image: self-organized format or raw file

[Kevin Wolf <kwolf@redhat.com>]

Am 14.08.2014 um 22:53 hat Xingbo Wu geschrieben:
> >> >> The main trick of QED was to introduce a dirty flag, which allowed to
> >> >> call fdatasync() less often because it was okay for image metadata to
> >> >> become inconsistent. After a crash, you have to repair the image then.
> >> >>
> >> >
> >> > I'm very curious about this dirty flag trick. I was surprised when I
> >> > observed very fast 'sync write' performance on QED.
> >> > If it skips the fdatasync when processing the device 'flush' command from
> >> > guest, it literally cheats the guest as the data can be lost. Am I that correct?
> >> > Does the repairing make sure all the data written before the last
> >> > successful 'flush'
> >> > can be recovered?
> >> > To my understanding, the 'flush' command in guest asks for persistence.
> >> > Data has to be persistent on host storage after flush except for the
> >> > image opened with 'cache=unsafe' mode.
> >> >
> >>
> >> I have some different ideas. Please correct me if I make any mistake.
> >> The trick may not cause true consistency issues. The relaxed write
> >> ordering (less fdatasync) seems to be safe.
> >> The analysis on this is described in this
> >> [http://lists.nongnu.org/archive/html/qemu-devel/2010-09/msg00515.html].
> >
> > Yes, specifically point 3. Without the dirty flag, you would have to
> > ensure that the file size is updated first and then the L2 table entry
> > is written. (This would still allow cluster leaks that cannot be
> > reclaimed, but at least no data corruption.)
> >
> >> In my opinion the reason why the ordering is irreverent is that any
> >> uninitialized block could exist in a block device.
> >> Unordered update l1 and alloc-write l2 are also safe because
> >> uninitialized blocks in a file is always zero or beyond the EOF.
> >
> > Yes. This holds true because QED (unlike qcow2) cannot be used directly
> > on block devices. This is a real limitation.
> >
> 
> I don't know much about the best practices in virtualization. Could
> you give me some examples? Thanks.
> Do some products provide resizeable (automatically?) Logical Volumes
> and put one qcow2 on each LV?
> Anyway, does someone use a physical disk to hold only one qcow2 image
> for some special usage?

I would be surprised if someone used a whole physical disk for a single
qcow2 image, but some people always do crazier things than you can
imagine...

Anyway, oVirt uses LVs to store qcow2 images on. It resizes the LVs on
the fly as they fill up. This seems to be working quite well.

Kevin