All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH][RFC] fast file mapping for loop
Date: Thu, 10 Jan 2008 08:46:18 -0500	[thread overview]
Message-ID: <20080110084618.6ca457f8@think.oraclecorp.com> (raw)
In-Reply-To: <20080110130324.GZ6258@kernel.dk>

On Thu, 10 Jan 2008 14:03:24 +0100
Jens Axboe <jens.axboe@oracle.com> wrote:

> On Thu, Jan 10 2008, Chris Mason wrote:
> > On Thu, 10 Jan 2008 08:54:59 +0000
> > Christoph Hellwig <hch@infradead.org> wrote:
> > 
> > > On Thu, Jan 10, 2008 at 09:44:57AM +0100, Jens Axboe wrote:
> > > > > IMHO this shouldn't be done in the loop driver anyway.
> > > > > Filesystems have their own effricient extent lookup trees
> > > > > (well, at least xfs and btrfs do), and we should leverage
> > > > > that instead of reinventing it.
> > > > 
> > > > Completely agree, it's just needed right now for this solution
> > > > since all we have is a crappy bmap() interface to get at those
> > > > mappings.
> > > 
> > > So let's fix the interface instead of piling crap ontop of it.
> > > As I said I think Peter has something to start with so let's beat
> > > on it until we have something suitable.   If we aren't done by
> > > end of Feb I'm happy to host a hackfest to get it sorted around
> > > the fs/storage summit..
> > > 
> > 
> > Ok, I've been meaning to break my extent_map code up, and this is a
> > very good reason.  I'll work up a sample today based on Jens' code.
> 
> Great!

Grin, we'll see how the sample looks.

> 
> > The basic goals:
> > 
> > * Loop (swap) calls into the FS for each mapping. Any caching
> > happens on the FS side.
> > * The FS returns an extent, filling any holes
> 
> We don't want to fill holes for a read, but I guess that's a given?

Right.

> 
> > Swap would need to use an extra call early on for preallocation.
> > 
> > Step two is having a call back into the FS allow the FS to delay the
> > bios until commit completion so that COW and delalloc blocks can be
> > fully on disk when the bios are reported as done.  Jens, can you add
> > some way to queue the bio completions up?
> 
> Sure, a function to save a completed bio and a function to execute
> completions on those already stored?
> 

Sounds right, I'm mostly looking for a way to aggregate a few writes to
make the commits a little larger.

-chris

  reply	other threads:[~2008-01-10 13:47 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-09  8:52 [PATCH][RFC] fast file mapping for loop Jens Axboe
2008-01-09  9:31 ` Christoph Hellwig
2008-01-09  9:43   ` Jens Axboe
2008-01-09 11:00     ` Chris Mason
2008-01-09 15:34 ` Andi Kleen
2008-01-10  8:43   ` Jens Axboe
2008-01-09 23:16 ` Alasdair G Kergon
2008-01-09 23:16   ` Alasdair G Kergon
2008-01-10  8:31   ` Jens Axboe
2008-01-10  8:42     ` Jens Axboe
2008-01-11  7:39       ` Mikulas Patocka
2008-01-11  7:58         ` Jens Axboe
2008-01-10 12:47     ` Chris Mason
2008-01-10 12:57       ` Jens Axboe
2008-01-10 23:01         ` Neil Brown
2008-01-11 14:21           ` Chris Mason
2008-01-10  1:42 ` Nick Piggin
2008-01-10  8:34   ` Jens Axboe
2008-01-10  8:37   ` Christoph Hellwig
2008-01-10  8:44     ` Jens Axboe
2008-01-10  8:54       ` Christoph Hellwig
2008-01-10  9:01         ` Jens Axboe
2008-01-10 12:53         ` Chris Mason
2008-01-10 13:03           ` Jens Axboe
2008-01-10 13:46             ` Chris Mason [this message]
2008-01-10  9:37     ` Peter Zijlstra
2008-01-10  9:49       ` Jens Axboe
2008-01-10  9:52         ` Peter Zijlstra
2008-01-10 10:02           ` Jens Axboe
2008-01-10 10:20             ` Peter Zijlstra
2008-01-11  1:25 ` Bill Davidsen
2008-01-11 18:17 ` Daniel Phillips
2008-01-11 18:23   ` Jens Axboe
2008-01-14 17:10 ` Chris Mason
2008-01-14 17:54   ` Jens Axboe
2008-01-15  9:25     ` Jens Axboe
2008-01-15  9:36       ` Jens Axboe
2008-01-15 10:07         ` Jens Axboe
2008-01-15 14:04           ` Chris Mason
  -- strict thread matches above, loose matches on Subject: below --
2008-01-09 23:43 devzero
2008-01-09 23:53 ` Alasdair G Kergon
2008-01-09 23:53   ` Alasdair G Kergon

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=20080110084618.6ca457f8@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=peterz@infradead.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 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.