This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: James Harper <james.harper@xxxxxxxxxxxxxxxx>, Simon Hobson <linux@xxxxxxxxxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-users] AoE (Was: iscsi vs nfs for xen VMs)
From: Jeff Sturm <jeff.sturm@xxxxxxxxxx>
Date: Fri, 28 Jan 2011 11:45:43 -0500
Delivery-date: Fri, 28 Jan 2011 08:47:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AEC6C66638C05B468B556EA548C1A77D01BB92E0@trantor>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <994429490908070648s69eed40eua19efc43c3eb85a7@xxxxxxxxxxxxxx><4D3FF9BC.40601@xxxxxxxxxxx><sig.4007da378a.AANLkTiku=-RhcyUZVHmwnJ18+Az6Fk5CxdEjKdHQKJ54@xxxxxxxxxxxxxx> <4D4032C7.9000003@xxxxxxxxxxx><AANLkTin+K5G10_03qLRT_yqCRELu339roLEHy1bVFoqR@xxxxxxxxxxxxxx><4D4064CD.8010005@xxxxxxxxxxx><AEC6C66638C05B468B556EA548C1A77D01BB9292@trantor><20110127083537.GD29664@xxxxxxxx><p06240870c96746abba41@xxxxxxxxxxxxxxxxxxxxxx> <64D0546C5EBBD147B75DE133D798665F0855BF00@xxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D01BB92E0@trantor>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acu+O/c+dWGuTCElT7+OEMCVh5x8zQADpZqgAAzN5sAAIrja4A==
Thread-topic: [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.

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


Xen-users mailing list