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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.