[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185817755.4023.7.camel@localhost.localdomain>
Date: Mon, 30 Jul 2007 10:49:14 -0700
From: Mingming Cao <cmm@...ibm.com>
To: Christoph Hellwig <hch@...radead.org>, akpm@...ux-foundation.org
Cc: Jeff Garzik <jeff@...zik.org>, Alex Tomas <alex@...sterfs.com>,
ext4 development <linux-ext4@...r.kernel.org>,
linux-fsdevel@...r.kernel.org
Subject: Re: [RFC] basic delayed allocation in VFS
On Sun, 2007-07-29 at 20:24 +0100, Christoph Hellwig wrote:
> On Sun, Jul 29, 2007 at 11:30:36AM -0600, Andreas Dilger wrote:
> > Sigh, we HAVE a patch that was only adding delalloc to ext4, but it
> > was rejected because "that functionality should go into the VFS".
> > Since the performance improvement of delalloc is quite large, we'd
> > like to get this into the kernel one way or another. Can we make a
> > decision if the ext4-specific delalloc is acceptable?
>
> I'm a big proponent of having proper common delalloc code, but the
> one proposed here is not generic for the existing filesystem using
> delalloc.
To be fair, what Alex have so far is probably good enough for ext2/3
delayed allocation.
> It's still on my todo list to revamp the xfs code to get
> rid of some of the existing mess and make it useable genericly. If
> the ext4 users are fine with the end result we could move to generic
> code.
>
Are you okay with having a ext4 delayed allocation implementation (i.e.
moving the code proposed in this thread to fs/ext4) first? Then later
when you come up with a generic delayed allocation for both ext4 and xfs
we could make use of that generic implementation. Is that a acceptable
approach?
Andrew, what do you think?
Regards,
Mingming
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists