From: David Chinner <dgc@sgi.com>
To: Alex Tomas <alex@clusterfs.com>
Cc: David Chinner <dgc@sgi.com>, Jeff Garzik <jeff@garzik.org>,
ext4 development <linux-ext4@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC] basic delayed allocation in VFS
Date: Mon, 30 Jul 2007 10:29:09 +1000 [thread overview]
Message-ID: <20070730002909.GY12413810@sgi.com> (raw)
In-Reply-To: <46AC8370.8050308@clusterfs.com>
On Sun, Jul 29, 2007 at 04:09:20PM +0400, Alex Tomas wrote:
> David Chinner wrote:
> >On Fri, Jul 27, 2007 at 11:51:56AM +0400, Alex Tomas wrote:
> >But this is really irrelevant - the issue at hand is what we want
> >for VFS level delalloc support. IMO, that mechanism needs to support
> >both XFS and ext4, and I'd prefer if it doesn't perpetuate the
> >bufferhead abuses of the past (i.e. define an iomap structure
> >instead of overloading bufferheads yet again).
>
> I'm not sure I understand very well.
->get_blocks abuses bufferheads to provide an offset/length/state
mapping. That's all it needs. That what the iomap structure is used
for. It's smaller than a bufferhead, it's descriptive of it's use
and you don't get it confused with the other 10 ways bufferheads
are used and abused.
> where would you track uptodate, dirty and other states then?
> do you propose to separate block states from block mapping?
No. They still get tracked in the bufferheads attached to the page.
That's what bufferheads were originally intended for(*).
Cheers,
Dave.
(*) I recently proposed a separate block map tree for this rather
than using buffer heads for this because of the memory footprint of
N bufferheads per page on contiguous mappings. That's future work,
not something we really need to consider here. Chris Mason's extent
map tree patches are a start on this concept.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2007-07-30 0:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 8:59 [RFC] basic delayed allocation in VFS Alex Tomas
2007-07-26 10:32 ` Jeff Garzik
2007-07-26 10:35 ` Alex Tomas
2007-07-26 12:05 ` Jeff Garzik
2007-07-26 13:33 ` Alex Tomas
2007-07-27 5:07 ` David Chinner
2007-07-27 7:51 ` Alex Tomas
2007-07-27 12:33 ` Jeff Garzik
2007-07-27 12:42 ` Alex Tomas
2007-07-28 19:56 ` Christoph Hellwig
2007-07-29 9:18 ` David Chinner
2007-07-29 12:09 ` Alex Tomas
2007-07-30 0:29 ` David Chinner [this message]
2007-07-27 12:38 ` Alex Tomas
2007-07-28 19:57 ` Christoph Hellwig
2007-07-28 19:53 ` Christoph Hellwig
2007-07-28 19:51 ` Christoph Hellwig
2007-07-28 19:56 ` Alex Tomas
2007-07-29 17:30 ` Andreas Dilger
2007-07-29 17:48 ` Alex Tomas
2007-07-29 19:22 ` Christoph Hellwig
2007-07-29 19:24 ` Christoph Hellwig
2007-07-29 19:51 ` Alex Tomas
2007-07-30 0:28 ` Theodore Tso
2007-07-30 17:49 ` Mingming Cao
2007-07-30 19:43 ` Andrew Morton
2007-07-26 11:47 ` 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=20070730002909.GY12413810@sgi.com \
--to=dgc@sgi.com \
--cc=alex@clusterfs.com \
--cc=hch@infradead.org \
--cc=jeff@garzik.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@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 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.