linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Chris Mason <chris.mason@oracle.com>,
	Nick Piggin <npiggin@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [patch 1/3] add the fsblock layer
Date: Tue, 26 Jun 2007 12:48:20 +1000	[thread overview]
Message-ID: <18048.32372.40011.10896@notabene.brown> (raw)
In-Reply-To: message from Nick Piggin on Tuesday June 26

On Tuesday June 26, nickpiggin@yahoo.com.au wrote:
> Chris Mason wrote:
> > 
> > The block device pagecache isn't special, and certainly isn't that much
> > code.  I would suggest keeping it buffer head specific and making a
> > second variant that does only fsblocks.  This is mostly to keep the
> > semantics of PagePrivate sane, lets not fuzz the line.
> 
> That would require a new inode and address_space for the fsblock
> type blockdev pagecache, wouldn't it? I just can't think of a
> better non-intrusive way of allowing a buffer_head filesystem and
> an fsblock filesystem to live on the same blkdev together.

I don't think they would ever try to.  Both filesystems would bd_claim
the blkdev, and only one would win.

The issue is more of a filesystem sharing a blockdev with the
block-special device (i.e. open("/dev/sda1"), read) isn't it?

If a filesystem wants to attach information to the blockdev pagecache
that is different to what blockdev want to attach, then I think "Yes"
- a new inode and address space is what it needs to create.

Then you get into consistency issues between the metadata and direct
blockdevice access.  Do we care about those?


NeilBrown

  reply	other threads:[~2007-06-26  2:48 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24  1:45 [RFC] fsblock Nick Piggin
2007-06-24  1:46 ` [patch 1/3] add the fsblock layer Nick Piggin
2007-06-24 15:28   ` Andi Kleen
2007-06-24 20:18     ` Arjan van de Ven
2007-06-25  8:58       ` Andi Kleen
2007-06-25  7:19     ` Nick Piggin
2007-06-24 23:01   ` Neil Brown
2007-06-25  7:41     ` Nick Piggin
2007-06-25 12:29       ` Chris Mason
2007-06-26  2:34         ` Nick Piggin
2007-06-26  2:48           ` Neil Brown [this message]
2007-06-26  3:07             ` Nick Piggin
2007-06-26 12:26               ` Chris Mason
2007-06-30 10:40                 ` Christoph Hellwig
2007-06-30 10:40           ` Christoph Hellwig
2007-06-25 13:19   ` Chris Mason
2007-06-26  2:42     ` Nick Piggin
2007-06-24  1:46 ` [patch 2/3] block_dev: convert to fsblock Nick Piggin
2007-06-24  1:47 ` [patch 3/3] minix: " Nick Piggin
2007-06-24  1:53 ` [RFC] fsblock Nick Piggin
2007-06-24  3:07 ` Jeff Garzik
2007-06-24  3:47   ` Nick Piggin
2007-06-24 13:51     ` Chris Mason
2007-06-25  6:58       ` Nick Piggin
2007-06-25 12:25         ` Chris Mason
2007-06-30 10:44           ` Christoph Hellwig
2007-06-30 10:42   ` Christoph Hellwig
2007-06-30 11:10     ` Jeff Garzik
2007-06-30 11:13       ` Christoph Hellwig
2007-06-24  4:19 ` William Lee Irwin III
2007-06-24 14:16 ` Andi Kleen
2007-06-25  7:16   ` Nick Piggin
2007-06-26  3:06 ` David Chinner
2007-06-26  3:55   ` Nick Piggin
2007-06-26  9:23     ` David Chinner
2007-06-26 11:14       ` Nick Piggin
2007-06-27 12:39         ` Kyle Moffett
2007-06-26 12:34       ` Chris Mason
2007-06-27  5:32         ` Nick Piggin
2007-06-27  6:05           ` David Chinner
2007-06-27 11:50           ` Chris Mason
2007-06-27 15:18             ` Anton Altaparmakov
2007-06-27 22:35             ` David Chinner
2007-06-28  2:44               ` Nick Piggin
2007-06-28 12:20                 ` Chris Mason
2007-06-29  2:08                   ` David Chinner
2007-06-29  2:33                   ` Nick Piggin
2007-06-30 11:05 ` Christoph Hellwig
2007-07-09 17:14 ` Christoph Lameter
2007-07-10  0:54   ` Nick Piggin
2007-07-10  0:59     ` Christoph Lameter
2007-07-10  1:07       ` Nick Piggin
2007-07-10  1:37       ` Dave McCracken

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=18048.32372.40011.10896@notabene.brown \
    --to=neilb@suse.de \
    --cc=chris.mason@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=npiggin@suse.de \
    /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).