From: CJ <cj@cjcj.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Dave Jones <davej@codemonkey.org.uk>,
Trond Myklebust <trond.myklebust@fys.uio.no>,
Dave Jones <davej@suse.de>, Chuck Lever <cel@monkey.org>
Subject: Re: Possible O_DIRECT problems ?
Date: Sat, 29 Dec 2001 10:46:04 -0800 [thread overview]
Message-ID: <3C2E0F6C.30608@cjcj.com> (raw)
In-Reply-To: <20011221000806.A26849@suse.de> <shssna58lpq.fsf@charged.uio.no> <20011221003942.B26268@codemonkey.org.uk> <20011229162542.G1356@athlon.random>
Shouldn't O_DIRECT's requirements come from the hardware? If we can
ASPI or CAM DMA SCSI devices to odd addresses and lengths, why not
O_DIRECT? Do ape drives DMA to user buffers? Are O_DIRECT's
current limits gratuitous?
Andrea Arcangeli wrote:
>On Fri, Dec 21, 2001 at 12:39:42AM +0000, Dave Jones wrote:
>
>>On Fri, Dec 21, 2001 at 01:23:45AM +0100, Trond Myklebust wrote:
>>
>> > O_DIRECT for NFS isn't yet merged into the kernel. Are these Chuck
>> > Lever's NFS patches you've been testing?
>>
>>Nope, stock 2.4.17rc2 & 2.5.1.
>>I thought NFS might just ignore the O_DIRECT flag if it didn't
>>understand it yet, I wasn't expecting such a dramatic failure.
>>
>
>The point of O_DIRECT is to do DMA directly into the userspace memory
>(and to avoid the VM overhead but that's a secondary issue and with data
>journaling we may need to put an anchor into the VM to serialize the
>direct I/O with the pagecache I/O in a secondary - slower - direct_IO
>callback for the data journaling fs).
>
>But to avoid the mem copies you're required to use strict alignment and
>size of the userspace buffers, just like rawio.
>
>If you don't you will get -EINVAL. This ensures people will use O_DIRECT
>correctly in their apps. In short every single bugreport like this about
>this -EINVAL strict behaviour is the proof we need to be strict and to
>return -EINVAL :)
>
>Andrea
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>.
>
next prev parent reply other threads:[~2001-12-29 18:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-21 0:08 Possible O_DIRECT problems ? Dave Jones
2001-12-21 0:23 ` Trond Myklebust
2001-12-21 0:39 ` Dave Jones
[not found] ` <w53ellp2out.wl@megaela.fe.dis.titech.ac.jp>
2001-12-21 12:46 ` Trond Myklebust
2001-12-21 16:14 ` Chuck Lever
2001-12-21 16:04 ` Chuck Lever
2001-12-29 15:25 ` Andrea Arcangeli
2001-12-29 18:46 ` CJ [this message]
2001-12-30 5:39 ` Andre Hedrick
2001-12-30 11:16 ` Gérard Roudier
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=3C2E0F6C.30608@cjcj.com \
--to=cj@cjcj.com \
--cc=cel@monkey.org \
--cc=davej@codemonkey.org.uk \
--cc=davej@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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