All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Miao Xie <miaox@cn.fujitsu.com>
Cc: Josef Bacik <josef@redhat.com>, viro <viro@zeniv.linux.org.uk>,
	Linux Fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ito <t-itoh@jp.fujitsu.com>
Subject: Re: [PATCH 1/3] direct-io: add a hook for the fs to provide its own bio merging check function
Date: Wed, 17 Nov 2010 20:24:39 -0500	[thread overview]
Message-ID: <1290043239-sup-7020@think> (raw)
In-Reply-To: <4CE47EDA.90205@cn.fujitsu.com>

Excerpts from Miao Xie's message of 2010-11-17 20:18:18 -0500:
> >> Right thats the idea, if we can't span chunks/stripes we should be doing that
> >> limiting in our get_blocks call and that way we don't have to screw with the
> >> generic direct io stuff too much.  Thanks,
> >
> > In this case we're adding complexity to the O_DIRECT mapping code, when
> > we really should be adding it to the btrfs submit bio hook.  It can
> > easily break up the bio into smaller units, which will leave us with a
> > smaller number of get_blocks calls overall.
> >
> > I'm working that out now.
> 
> Do you mean you are fixing this bug now?

I started on it this afternoon, but lost network due to high winds here.
So, I didn't make any real progress.

If you'd like to fix this in the btrfs direct-io bio submit call you're
welcome to continue working on it.

The idea is to just clone and split up the bio, which will keep us from
filling up fs/direct-io.c w/btrfs rules and allow us to take fewer
trips into the get_blocks call.

-chris

  reply	other threads:[~2010-11-18  1:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  4:18 [PATCH 1/3] direct-io: add a hook for the fs to provide its own bio merging check function Miao Xie
2010-11-17  7:06 ` Josef Bacik
2010-11-17  9:37   ` Josef Bacik
2010-11-17 10:11     ` Miao Xie
2010-11-17 12:50       ` Josef Bacik
2010-11-17 16:55         ` Chris Mason
2010-11-18  1:18           ` Miao Xie
2010-11-18  1:24             ` Chris Mason [this message]
2010-11-18  1:33               ` Miao Xie

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=1290043239-sup-7020@think \
    --to=chris.mason@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miaox@cn.fujitsu.com \
    --cc=t-itoh@jp.fujitsu.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.