All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Theodore Tso <tytso@mit.edu>, Curt Wohlgemuth <curtw@google.com>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH RFC] Insure direct IO writes do not use the page cache
Date: Thu, 30 Jul 2009 14:16:32 -0500	[thread overview]
Message-ID: <4A71F190.3050209@redhat.com> (raw)
In-Reply-To: <20090730184448.GC24295@duck.suse.cz>

Jan Kara wrote:
> On Thu 30-07-09 13:39:12, Eric Sandeen wrote:
...

							Honza
>> This is all about right, but it's tricky, because right now, get_block
>> is called in the direct IO path from get_more_blocks(), and it's called
>> with create == 0 unless OWN_LOCKING is specified.  If we do get_block w/
>> create == 0 and find prealloc'd blocks, then we're given back unmapped
>> buffer heads. This looks like a hole, and so DIO falls back to buffered.
>>
>> Right now the only way to get create == 1 sent to get_blocks via
>> directio is to do OWN_LOCKING, which implies... we have to do our own
>> locking, and it'll take some time to get it right I think.
>   But the get_block function called by get_more_blocks() is specified in
> ext4_direct_IO. So we can provide it with a special direct_IO version of
> get_block function which happily maps also uninitialized extents... It's a
> slight hack, but maintainable IMHO.

Hm, perhaps.  xfs does have a xfs_get_blocks_direct() that it uses for DIO.

Although returning mapped unwritten blocks ... well, we'll have to be
sure it doesn't cause any problems elsewhere.  :)

-Eric

> 									Honza


  reply	other threads:[~2009-07-30 19:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-29  0:28 [PATCH RFC] Insure direct IO writes do not use the page cache Curt Wohlgemuth
2009-07-29 16:10 ` Curt Wohlgemuth
2009-07-29 17:18   ` Eric Sandeen
2009-07-29 17:41     ` Eric Sandeen
2009-07-29 19:48     ` Eric Sandeen
2009-07-29 22:17       ` Mingming
2009-07-29 17:47 ` Mingming
2009-07-29 18:10 ` Theodore Tso
2009-07-30 18:30   ` Jan Kara
2009-07-30 18:39     ` Eric Sandeen
2009-07-30 18:44       ` Jan Kara
2009-07-30 19:16         ` Eric Sandeen [this message]
2009-07-30 20:33     ` Theodore Tso
2009-07-31 16:10       ` Curt Wohlgemuth
2009-08-01  6:56         ` [PATCH RFC] ext4 direct IO for holes, fallocate Mingming
2009-08-03 16:47           ` Aneesh Kumar K.V
2009-08-03 23:40             ` Mingming
2009-07-31 17:58       ` [PATCH RFC] Insure direct IO writes do not use the page cache Mingming
2009-07-31 18:03         ` Michael Rubin
2009-07-31 18:03           ` Michael Rubin
2009-08-03  9:36       ` Jan Kara
2009-07-30 11:06 ` Aneesh Kumar K.V

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=4A71F190.3050209@redhat.com \
    --to=sandeen@redhat.com \
    --cc=curtw@google.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.