All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.