All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: 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 11:24:57 -0700	[thread overview]
Message-ID: <20060630182457.GH11640@ca-server1.us.oracle.com> (raw)
In-Reply-To: <1151687586.339.5.camel@dyn9047017100.beaverton.ibm.com>

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.
	The same with metadata/data ordering issues.  ie, data=ordered
or even plain "creat(2); write(2)".  I don't know how generic the
ordering is for each filesystem, but there is always room for play.
	On-disk, of course each filesystem is going to be different.
I'm not sure we could fit a fully-generic aops->reserve_space() &
aops->commit_space() API.  But I don't think we need to.

Joel
-- 

"Well-timed silence hath more eloquence than speech."  
         - Martin Fraquhar Tupper

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

  reply	other threads:[~2006-06-30 18:28 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 [this message]
2006-06-30 19:17         ` Steve Lord
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=20060630182457.GH11640@ca-server1.us.oracle.com \
    --to=joel.becker@oracle.com \
    --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.