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

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

> > -----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.

That's the poor mans barrier. Not great for performance if you have to
do it too often though as you can't send the next requests until the
previous ones are complete.

> > 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
> 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.

It would require a semi-reliable protocol, which I thought they already


Xen-users mailing list



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