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

[Avi Kivity <avi@qumranet.com>]

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.