Re: [Qemu-devel] Re: [PATCH][v2] Align file accesses with cache=off (O_DIRECT)

[Anthony Liguori <anthony@codemonkey.ws>]

Paul Brook wrote:
> On Wednesday 21 May 2008, Anthony Liguori wrote:
>   
>> Paul Brook wrote:
>>     
>>>> When sector-aligned guest offsets are converted to sector-unaligned
>>>> writes (e.g. due to qcow2 etc.), that property is no longer satisfied,
>>>> and power failure of the host disk can cause more damage than the
>>>> guest is designed to be resistant to.
>>>>         
>>> Seems like the easiest solution would be to have qcow always align its
>>> writes. We don't do on the fly compression, so it should be fairly easy
>>> to make this happen with minimal overhead.
>>>       
>> That's not sufficient. O_DIRECT imposes not only offset alignment
>> requirements but also requirements on the buffer being read to. Most of
>> the code in QEMU does not properly align the read/write buffers.
>>     
>
> In that case you need both. For correct operation the qcow layer needs to 
> ensure that all file offsets are block aligned (amongst other things, I 
> wouldn't be surprised if there are more subtle problems with metadata 
> updates).
>
> The memory buffer alignment can occur wherever is most convenient, that's 
> trivially atomic w.r.t. unexpected interruptions.
>   

Yes, I don't think qcow is very safe at all wrt unexpected power events. 
If we're going to support O_DIRECT, then it's important that underlying 
block device emulate accesses that don't meet the requirements of 
O_DIRECT. IMHO, this should all happen within block-raw-posix.c.

Keep in mind, the requirements for O_DIRECT since 2.5 is hard sector 
size (which is usually 512 bytes, but not always) for offset, buffer, 
and size. Pre-2.5, the requirement is soft sector size which on a 
filesystem is usually 4k.

I don't think it's that important to try and guess the right alignment 
size, 512 is probably usually sufficient, but spreading alignment 
requirements of 512 throughout QEMU code is a bad idea because this is 
something that's very hardware/OS specific.

For people that care about data integrity, we should be using O_SYNC, 
not O_DIRECT anyway.

Regards,

Anthony Liguori

> Paul
>