Re: [Qemu-devel] qcow2 - safe on kill? safe on power fail?

[Avi Kivity]

Anthony Liguori wrote:
> Jamie Lokier wrote:
> > > If the sector hasn't been previously allocated, then a new sector in 
> > > the file needs to be allocated.  This is going to change metadata 
> > > within the QCOW2 file and this is where it is possible to corrupt a 
> > > disk image.  The operation of allocating a new disk sector is 
> > > completely synchronous so no other code runs until this completes.  
> > > Once the disk sector is allocated, you're safe again[1].
> > >     
> >
> > My main concern is corruption of the QCOW2 sector allocation map, and
> > subsequently QEMU/KVM breaking or going wildly haywire with that file.
> >
> > With a normal filesystem, sure, there are lots of ways to get
> > corruption when certain events happen.  But you don't lose the _whole_
> > filesystem.
> >   
>
> Sure you can.  If you don't have a battery backed disk cache and are 
> using write-back (which is usually the default), you can definitely 
> get corruption of the journal.  Likewise, under the right scenarios, 
> you will get journal corruption with the default mount options of ext3 
> because it doesn't use barriers.

What about SCSI or SATA NCQ?  On these, barriers don't impact 
performance greatly.

> This is very hard to see happen in practice though because these 
> windows are very small--just like with QEMU.

The exposure window with qemu is not small.  It's as large as the page 
cache of the host.

> > > you are running QEMU with cache=off to disable host write caching.      
> >
> > Doesn't that use O_DIRECT?  O_DIRECT writes don't use barriers, and
> > fsync() does not deterministically issue a disk barrier if there's no
> > metadata change, so O_DIRECT writes are _less_ safe with disks which
> > have write-cache enabled than using normal writes.
> >   
>
> It depends on the filesystem.  ext3 never issues any barriers by 
> default :-)
>
> I would think a good filesystem would issue a barrier after an 
> O_DIRECT write.

Using a disk controller that supports queueing means that you can (in 
theory at least) leave writeback turned on and yet have the disk not lie 
to you about completions.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.