linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Curt Wohlgemuth <curtw@google.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH RFC] Insure direct IO writes do not use the page cache
Date: Wed, 29 Jul 2009 12:18:09 -0500	[thread overview]
Message-ID: <4A708451.4060908@redhat.com> (raw)
In-Reply-To: <6601abe90907290910x7cf1122cwac689d1f106326d3@mail.gmail.com>

Curt Wohlgemuth wrote:
> Although replying to self is somewhat bad etiquette...

nah :)

> I've found at least one issue with this patch:  Although the semantics
> seem correct, since the late-converted-to-init extents are not merged
> with neighbors, you can easily end up with thousands of extents :-( .
> Each write to fallocate'd space results in its own initialized extent.
> 
> I'm not sure how expensive it would be to merge the extents when they
> are converted to initialized after the DIO write goes through.
> 
> Curt
> 

hm I think I've seen other cases where things don't get merged as well
as I'd expect.

I haven't replied to the first mail yet because I have a lot of
remembering to do about xfs first, but I'm fairly certain that at least
your use of blockdev_direct_IO_own_locking() is not correct.  See for
example all the comments around __blockdev_direct_IO about i_mutex, and
all the xfs_ilock/xfs_iolock calls in xfs_read/xfs_write.

There is a lot of locking for the fs to handle if you want to go that route.

Also, IIRC xfs does the conversion to written (vs. unwritten) extents in
an IO completion handler, just FWIW.

-Eric

  reply	other threads:[~2009-07-29 17:18 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 [this message]
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
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=4A708451.4060908@redhat.com \
    --to=sandeen@redhat.com \
    --cc=curtw@google.com \
    --cc=linux-ext4@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).