Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support.

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 5/11/08 08:16, "Joe Jin" <joe.jin@xxxxxxxxxx> wrote:

>> What's the vbd type in this case: raw partition, lvm, qcow file, ...?
> 
> Raw partition, crashed/power outage, lots of data lost :(
> 
>> The existing BLKIF_OP_WRITE_BARRIER and BLKIF_OP_FLUSH_DISKCACHE should
>> suffice to implement O_SYNC on the blkfront side, I think. O_DIRECT doesn't
>> mean writes are synchronous to the platters -- just means the buffer cache
>> is bypassed -- which should generally be the case on the blkback side always
>> anyway.
> 
> However, frontend driver could not got the write's flag at all.
> if we could know the request with O_SYNC flag should be easy to handle,
> need not touch filesystem layer.

So what does O_SYNC mean to Linux then? If it's not passed down to the
blkdev layer then it can only mean that requests must be synchronously
committed as far as that layer. I would therefore imagine you could lose as
much data natively as you do running on Xen. Where are these megabytes of
data sitting when they get lost, and why does it not happen when running
natively? If O_SYNC is not waiting for completion responses from the block
layer, that's a limitation of Linux's generic block subsystem, isn't it?

 -- Keir

> O_DIRECT is difference not only buffer head, if read/write is direct-io,
> need to commit request as soon as possible, means unplug request_queue
> if request with O_DIRECT flag(request should be marked REQ_RW_SYNC
> flag).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel