Re: Proposal and plan for ext2/3 future development work

[Badari Pulavarty <pbadari@us.ibm.com>]

On Thu, 2006-06-29 at 18:59 -0700, Joel Becker wrote:
> On Thu, Jun 29, 2006 at 09:14:53PM -0400, Jeff Garzik wrote:
> > Agreed overall, though specifically for delayed allocation I think 
> > that's an ext4 thing:
> > 
> > * First off, I'm a big fan of delalloc, and (like extents) definitely 
> > want to see the feature implemented
> > * Delayed allocation, properly done, requires careful interaction with 
> > VM writeback (memory pressure or normal writeout), and may require some 
> > minor changes to generic code in fs/* and mm/*
> 
> 	To be honest, I'd like to see more delayed allocation
> infrastructure in the VFS itself.  XFS has to maintain an entire chunk
> of state for it, and I suspect ext4 will as well.  I'd love to get
> delayed allocation into OCFS2 someday.  Why not move to where we can
> share the in-memory accounting code?
> 	Now, we'd probably want to start by prototyping it in ext4
> directly.  Once it's stable as a filesystem feature, we can see where
> XFS and ext4 overlap, etc, etc.  But I'd like to keep a more generic
> direction in mind.

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.

If you have ideas on what are the common/generic stuff we can do in
VFS - I can take a look at it again :)

Thanks,
Badari

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/