|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support.
To: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
Subject: |
Re: [Xen-devel] [patch 0/6] xenblk: Add O_DIRECT and O_SYNC support. |
From: |
Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> |
Date: |
Wed, 5 Nov 2008 11:26:00 +0000 |
Cc: |
Xen-Devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Kurt Hackel <kurt.hackel@xxxxxxxxxx>, Jens, Greg Marsden <greg.marsden@xxxxxxxxxx>, Joe Jin <joe.jin@xxxxxxxxxx>, Wen Gang Wang <wen.gang.wang@xxxxxxxxxx>, Axboe <jens.axboe@xxxxxxxxxx>, Shinya Narahara <shinya.narahara@xxxxxxxxxx> |
Delivery-date: |
Wed, 05 Nov 2008 03:26:22 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<C5371309.1EE5C%keir.fraser@xxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
Organization: |
Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 |
References: |
<53f6a65d-b8f3-477d-9e00-fbe29880d739@default> <C5371309.1EE5C%keir.fraser@xxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> 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
The block device layer speaks ordering barriers not file flags. The O_SYNC
flag is passed to the file system the file system is responsible for
turning that into some type of ordering, ditto stuff like fdatasync(). The
exact behaviour is then configuable by the fs (eg ext3 has journalled and
non journalled data modes)
In terms of data integrity if you are relying on the order of physical
media writes internally in Xen you already lost as there is nothing in
most ATA specs requiring that a sequence of I/O operations occurs in the
order they go to the drive. The sematics of cache flushing versus other
I/O are defined so you have ordering points you can impose and some
control over the time stuff may sit around before hitting disk.
Alan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|