From: David Chinner <dgc@sgi.com>
To: Christoph Hellwig <hch@infradead.org>,
David Chinner <dgc@sgi.com>, Alex Tomas <alex@clusterfs.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] delayed allocation for ext4
Date: Fri, 29 Dec 2006 13:50:06 +1100 [thread overview]
Message-ID: <20061229025006.GN44411608@melbourne.sgi.com> (raw)
In-Reply-To: <20061223092718.GA26276@infradead.org>
On Sat, Dec 23, 2006 at 09:27:18AM +0000, Christoph Hellwig wrote:
> On Sat, Dec 23, 2006 at 02:31:23PM +1100, David Chinner wrote:
> > > - ext4-delayed-allocation.patch
> > > delayed allocation itself, enabled by "delalloc" mount option.
> > > extents support is also required. currently it works only
> > > with blocksize=pagesize.
> >
> > Ah, that's why you can get away with a page flag - you've ignored
> > the partial page delay state problem. Any plans to use the
> > existing method in the future so we will be able to use ext4 delalloc
> > on machines with a page size larger than 4k?
>
> I think fixing this up for blocksize < pagesize is an absolute requirement
> to get things merged. We don't need more filesystems that are crippled
> on half of our platforms.
>
> Note that recording delayed alloc state at a page granularity in addition
> to just the buffer heads has a lot of advantages aswell and would help
> xfs, too. But I think it makes a lot more sense to record it as a radix
> tree tag to speed up the gang lookups for delalloc conversion.
I'm not sure it will make that much difference, really. Looking up
by delalloc tag is only going to save a few tail pages in pagevec we
use for the look up and could be more expensive if delalloc pages
are sparsely distributed through the file.
We'd still have to keep the bufferheads around for partial page
state, and that becomes an interesting exercise in keeping things
coherent between the radix tree and the buffer heads.
Of course, then there's the unwritten state that XFS also carries
around per block (bufferhead) which has all the same issues as the
delalloc state. I'd hate to have a generic method for handling
delalloc state which is different from the handling of the unwritten
state and needing two different sets of code to handle what is
essentially the same thing....
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2006-12-29 2:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-22 20:20 Alex Tomas
2006-12-22 20:23 ` [RFC] booked-page-flag.patch Alex Tomas
2006-12-22 20:25 ` [RFC] ext4-block-reservation.patch Alex Tomas
2006-12-23 22:40 ` Andrew Morton
2006-12-23 22:47 ` Alex Tomas
2006-12-22 20:28 ` [RFC] ext4-delayed-allocation.patch Alex Tomas
2006-12-23 22:59 ` Andrew Morton
2006-12-23 3:31 ` [RFC] delayed allocation for ext4 David Chinner
2006-12-23 9:27 ` Christoph Hellwig
2006-12-23 19:15 ` Alex Tomas
2006-12-29 2:50 ` David Chinner [this message]
2006-12-23 19:09 ` Alex Tomas
2006-12-29 2:52 ` David Chinner
2006-12-29 4:56 ` Alex Tomas
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=20061229025006.GN44411608@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=alex@clusterfs.com \
--cc=hch@infradead.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®