RE: [Xen-users] AoE (Was: iscsi vs nfs for xen VMs)

[Jeff Sturm <jeff.sturm@xxxxxxxxxx>]

> -----Original Message-----
> From: James Harper [mailto:james.harper@xxxxxxxxxxxxxxxx]
>  
> It sounds like AoE would make this even worse if the 'first'
> write was lost resulting in the 'second' write being performed
> first followed by the 'first' write.

Keep in mind that AoE is a synchronous protocol (although the upper
layers can make it appear to be asynchronous).

If you issue two write requests concurrently, they can complete in any
order.  If you issue one request, wait for the response, then issue a
2nd request (i.e. with fsync), they *should* happen sequentially.

> Now sensibly, you'd think that a barrier would be placed
> between the first and second writes guaranteeing that nothing 
> would be reordered across the barrier,

Yup.  I understand the point about disks that reorder requests
internally.  I wonder if Coraid plans to implement barriers in a future
version of the protocol.  There are flag bits marked "reserved for
future use", so it should be straightforward to implement in a
backward-compatible fashion.

> but if you run Windows on Xen on AoE on DRBD (eg to a HA 
> DRBD SAN), you might see non-sensible things happen.

Definitely.  There are plenty of layers that can get things wrong.  I've
mentioned in a past post here on this list that we experienced
infrequent corruption of a cluster filesystem until we used "tap:sync"
for our shared domU storage volumes.


-Jeff



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