From: Steve Lord <lord@sgi.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Chris Wedgwood <cw@f00f.org>, Jeff Garzik <garzik@havoc.gtf.org>,
Chris Mason <mason@suse.com>, Andrea Arcangeli <andrea@suse.de>,
Andrew Morton <akpm@zip.com.au>, Ricardo Galli <gallir@uib.es>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: O_DIRECT fails in some kernel and FS
Date: 04 Feb 2002 10:02:26 -0600 [thread overview]
Message-ID: <1012838546.26363.588.camel@jen.americas.sgi.com> (raw)
In-Reply-To: <E16XlK0-0007Wu-00@the-village.bc.nu>
In-Reply-To: <E16XlK0-0007Wu-00@the-village.bc.nu>
On Mon, 2002-02-04 at 09:46, Alan Cox wrote:
> > If an application is multithreaded and is doing mmap and direct I/O
> > from different threads without doing its own synchronization, then it
> > is broken, there is no ordering guarantee provided by the kernel as
> > to what happens first.
>
> Providing we don't allow asynchronous I/O with O_DIRECT once asynchronous
> I/O is merged.
But async I/O itself needs synchronisation (being English in this email ;-)
to be meaningful. If I issue a bunch of async I/O calls which overlap with
each other then the outcome is really undefined in terms of what ends up
on the disk. Scheduling of the actual I/O operations is really no different
from them being synchronous calls from different user space threads.
The only questions you can really ask is 'is read atomic with respect to
write?' and 'are writes atomic with respect to each other?'. So when you
perform a read it sees data from before or after writes, but never sees
data from half way through a write. And for multiple write calls the output
appears as if one write happened after the other, not intermingled
with each other.
Irix actually takes the viewpoint that it only needs to make a best effort
at synchronizing between direct I/O and other modes of I/O. Multiple
direct writers are allowed into a file at once, and direct writers and
buffered readers are also allowed to operate in parallel. At this point
coherency is really up to the applications. I am not presenting this as
a recommended model for linux, just reporting what it does.
>
> Alan
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@sgi.com
next prev parent reply other threads:[~2002-02-04 16:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-01 20:37 Ricardo Galli
2002-02-01 20:44 ` Andrew Morton
2002-02-01 20:49 ` Ricardo Galli
2002-02-01 20:57 ` Andrew Morton
2002-02-02 17:14 ` Christoph Hellwig
2002-02-01 21:05 ` Steve Lord
2002-02-02 9:35 ` Chris Wedgwood
2002-02-02 10:25 ` Hans Reiser
2002-02-02 15:24 ` Chris Mason
2002-02-02 18:20 ` Chris Mason
2002-02-02 19:54 ` Andrea Arcangeli
2002-02-02 20:10 ` Chris Mason
2002-02-02 20:16 ` Stephen Lord
2002-02-02 20:50 ` Jeff Garzik
2002-02-03 13:40 ` Stephen Lord
2002-02-03 14:09 ` Chris Wedgwood
2002-02-03 15:05 ` Stephen Lord
2002-02-03 22:44 ` Chris Wedgwood
2002-02-04 15:04 ` Jeff Garzik
2002-02-04 15:21 ` Chris Mason
2002-02-04 15:15 ` Steve Lord
2002-02-04 15:46 ` Alan Cox
2002-02-04 16:02 ` Steve Lord [this message]
2002-02-04 18:22 ` Daniel Phillips
2002-02-04 19:11 ` Steve Lord
2002-02-04 18:29 ` Joel Becker
2002-02-04 18:49 ` Jeff Garzik
2002-02-04 18:55 ` Joel Becker
2002-02-04 19:16 ` Jeff Garzik
[not found] <E16WkQj-0005By-00@antoli.uib.es.suse.lists.linux.kernel>
[not found] ` <3C5AFE2D.95A3C02E@zip.com.au.suse.lists.linux.kernel>
[not found] ` <1012597538.26363.443.camel@jen.americas.sgi.com.suse.lists.linux.kernel>
[not found] ` <20020202093554.GA7207@tapu.f00f.org.suse.lists.linux.kernel>
[not found] ` <234710000.1012674008@tiny.suse.lists.linux.kernel>
[not found] ` <20020202205438.D3807@athlon.random.suse.lists.linux.kernel>
[not found] ` <242700000.1012680610@tiny.suse.lists.linux.kernel>
[not found] ` <3C5C4929.5080403@sgi.com.suse.lists.linux.kernel>
[not found] ` <20020202155028.B26147@havoc.gtf.org.suse.lists.linux.kernel>
2002-02-03 7:26 ` Andi Kleen
2002-02-04 15:13 ` Jeff Garzik
2002-02-04 15:31 ` Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1012838546.26363.588.camel@jen.americas.sgi.com \
--to=lord@sgi.com \
--cc=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andrea@suse.de \
--cc=cw@f00f.org \
--cc=gallir@uib.es \
--cc=garzik@havoc.gtf.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®