All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: suparna@in.ibm.com
Cc: pbadari@us.ibm.com, daniel@osdl.org, sebastien.dugue@bull.net,
	linux-aio@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.6.10 -  direct-io async short read bug
Date: Wed, 9 Mar 2005 11:53:48 -0800	[thread overview]
Message-ID: <20050309115348.2b86b765.akpm@osdl.org> (raw)
In-Reply-To: <20050309152047.GA4588@in.ibm.com>

Suparna Bhattacharya <suparna@in.ibm.com> wrote:
>
>  > 	Solaris, which does forcedirectio as a mount option, actually
>  > will do buffered I/O on the trailing part.  Consider it like a bounce
>  > buffer.  That way they don't DMA the trailing data and succeed the I/O.
>  > The I/O returns actual bytes till EOF, just like read(2) is supposed to.
>  > 	Either this or a fully DMA'd number 4 is really what we should
>  > do.  If security can only be solved via a bounce buffer, who cares?  If
>  > the user created themselves a non-aligned file to open O_DIRECT, that's
>  > their problem if the last part-sector is negligably slower.
> 
>  If writes/truncates take care of zeroing out the rest of the sector
>  on disk, might we still be OK without having to do the bounce buffer
>  thing ?

We can probably rely on the rest of the sector outside i_size being zeroed
anyway.  Because if it contains non-zero gunk then the fs already has a
problem, and the user can get at that gunk with an expanding truncate and
mmap() anyway.



  reply	other threads:[~2005-03-09 20:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-07 10:00 [PATCH] 2.6.10 - direct-io async short read bug Sébastien Dugué
2005-03-08  6:39 ` Andrew Morton
2005-03-08  9:09   ` Suparna Bhattacharya
2005-03-08  9:18     ` Andrew Morton
2005-03-08  9:41       ` Suparna Bhattacharya
2005-03-08  9:41         ` Andrew Morton
2005-03-08 10:27           ` Suparna Bhattacharya
2005-03-08 10:27             ` Andrew Morton
2005-03-08 17:23     ` Badari Pulavarty
2005-03-08 19:18       ` Badari Pulavarty
2005-03-08 23:27         ` Daniel McNeil
2005-03-08 23:54           ` Badari Pulavarty
2005-03-09  4:07             ` Joel Becker
2005-03-09  9:50               ` Sébastien Dugué
2005-03-09 15:20               ` Suparna Bhattacharya
2005-03-09 19:53                 ` Andrew Morton [this message]
2005-03-09 21:18                   ` Joel Becker
2005-03-09 21:31                   ` Badari Pulavarty
2005-03-09 22:39                     ` Andrew Morton
2005-03-09 22:45                       ` Badari Pulavarty
2005-03-09  1:44         ` Daniel McNeil
2005-03-09 15:58           ` Badari Pulavarty
  -- strict thread matches above, loose matches on Subject: below --
2005-03-08  9:46 Sébastien Dugué
2005-03-08 10:16 Sébastien Dugué

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=20050309115348.2b86b765.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=daniel@osdl.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sebastien.dugue@bull.net \
    --cc=suparna@in.ibm.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 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.