public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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/
>
>.
>



  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