All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, chris.mason@oracle.com,
	linux-fsdevel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH][RFC] fast file mapping for loop
Date: Wed, 9 Jan 2008 10:43:21 +0100	[thread overview]
Message-ID: <20080109094320.GA6258@kernel.dk> (raw)
In-Reply-To: <20080109093107.GA5023@infradead.org>

On Wed, Jan 09 2008, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 09:52:32AM +0100, Jens Axboe wrote:
> > - The file block mappings must not change while loop is using the file.
> >   This means that we have to ensure exclusive access to the file and
> >   this is the bit that is currently missing in the implementation. It
> >   would be nice if we could just do this via open(), ideas welcome...
> 
> And the way this is done is simply broken.  It means you have to get
> rid of things like delayed or unwritten hands beforehand, it'll be
> a complete pain for COW or non-block backed filesystems.

COW is not that hard to handle, you just need to be notified of moving
blocks. If you view the patch as just a tighter integration between loop
and fs, I don't think it's necessarily that broken.

I did consider these cases, and it can be done with the existing
approach.

> The right way to do this is to allow direct I/O from kernel sources
> where the filesystem is in-charge of submitting the actual I/O after
> the pages are handed to it.  I think Peter Zijlstra has been looking
> into something like that for swap over nfs.

That does sound like a nice approach, but a lot more work. It'll behave
differently too, the advantage of what I proposed is that it behaves
like a real device.

I'm not asking you to love it (in fact I knew some people would complain
about this approach and I understand why), just tossing it out there to
get things rolling. If we end up doing it differently I don't really
care, I'm not married to any solution but merely wish to solve a
problem. If that ends up being solved differently, the outcome is the
same to me.

-- 
Jens Axboe


  reply	other threads:[~2008-01-09  9:43 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 [this message]
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
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=20080109094320.GA6258@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=chris.mason@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.