[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

>> O_DIRECT has no meaning really across the xenblk interface. The intention is
>> that blkback talks at a raw block device below the buffer cache anyway.
>> 
>> For O_SYNC it can be implemented by pushing out all I/Os into the ring
>> buffer and then wait for all required responses. Why do you think that
>> doesn't work? Indeed it should work already if such logic exists in the
>> generic Linux block layer, since blkfront notifies that layer as responses
>> come in from blkback.
>> 
> Do you think when xenblk backend make_reponse() means the request have
> commited to disk?
> We have did a sample testing and found without BI_RW_SYNC flag setted,
> either O_DIRECT or O_SYNC flag, when vm crashed/power outage, lots of
> data lost, sometimes more than 1M data lost, that means vm under
> high data lost risk. With BI_RW_SYNC flag when call submit_bio, open
> file with O_DIRECT or O_SYNC flag, could sync data very well.

What's the vbd type in this case: raw partition, lvm, qcow file, ...?

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.

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.