From: Steve Lord <lord@xfs.org>
To: Badari Pulavarty <pbadari@us.ibm.com>,
Jeff Garzik <jeff@garzik.org>, "Theodore Ts'o" <tytso@mit.edu>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Proposal and plan for ext2/3 future development work
Date: Fri, 30 Jun 2006 14:17:00 -0500 [thread overview]
Message-ID: <44A578AC.3010709@xfs.org> (raw)
In-Reply-To: <20060630182457.GH11640@ca-server1.us.oracle.com>
Joel Becker wrote:
> On Fri, Jun 30, 2006 at 10:13:06AM -0700, Badari Pulavarty wrote:
>> I tried adding "delayed allocation" for ext3 earlier. Yes. VFS level
>> infrastructure would be nice. But, I haven't found much that we can
>> do at VFS - which is common across all the filesystems (except
>> mpage_writepage(s) handling). Most of the stuff is specific to
>> filesystem implementation (even though it could be common) - coming
>> out with VFS level interfaces to suite all the different filesystem
>> delalloc would be *interesting* exercise.
>
> Well, to be fair, I'm just going by what little I know about
> XFS. They maintain a cache of all pages waiting on delayed allocation
> for writepack. Why have this entire cache (hash, list, whatever) when
> we could create some state on in the pagecache? We save a large chunk
> of memory and some complex writeback code. I suspect you were thinking
> of this when you said "mpage_writepage(s) handling". But this is a
> large complexity win if we can do it.
No, XFS does not do this, when it gets asked to write out a page which is
delayed alloc, it goes and converts the delayed alloc extent to real disk
space. It then uses the page cache/buffer heads to find all the contiguous
pages which it can turn into a singe disk I/O. The code is made more complex
by other possible states for the data. The only information internal to XFS
though is its extent structures.
Steve
next prev parent reply other threads:[~2006-06-30 19:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 23:55 Proposal and plan for ext2/3 future development work Theodore Ts'o
2006-06-30 1:14 ` Jeff Garzik
2006-06-30 1:59 ` Joel Becker
2006-06-30 17:13 ` Badari Pulavarty
2006-06-30 18:24 ` Joel Becker
2006-06-30 19:17 ` Steve Lord [this message]
2006-06-30 19:29 ` Badari Pulavarty
2006-06-30 10:39 ` Andi Kleen
2006-06-30 15:14 ` Theodore Tso
2006-07-01 9:42 ` Adrian Bunk
2006-07-01 10:29 ` Theodore Tso
2006-06-30 11:09 ` Patrick McFarland
2006-06-30 23:44 ` Mingming Cao
2006-07-24 13:04 ` Guillaume Chazarain
2006-07-24 18:11 ` Jeff Garzik
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=44A578AC.3010709@xfs.org \
--to=lord@xfs.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=tytso@mit.edu \
/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