[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1166016989.5059.13.camel@kleikamp.austin.ibm.com>
Date: Wed, 13 Dec 2006 07:36:29 -0600
From: Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Cc: Mingming Cao <cmm@...ibm.com>, linux-ext4@...r.kernel.org,
suparna@...ibm.com, suzuki@...ibm.com
Subject: Re: [RFC][Patch 1/1] Persistent preallocation in ext4
On Wed, 2006-12-13 at 15:31 +0530, Amit K. Arora wrote:
> On Tue, Dec 12, 2006 at 04:20:38PM -0800, Mingming Cao wrote:
> > On Tue, 2006-12-12 at 11:53 +0530, Amit K. Arora wrote:
> > Supporting preallocation for extent based files seems fairly
> > straightforward. I agree we should look at this first. After get this
> > done, it probably worth re-consider whether to support preallocation for
> > non-extent based files on ext4. I could imagine user upgrade from ext3
> > to ext4, and expecting to use preallocation on those existing files....
I disagree here. Why add the complexity for what is going to be a rare
case? In cases where a user is going to benefit from preallocation,
she'll probably also benefit from extents, and would be better off
making a copy of the file, thus converting it to extents.
> I gave a thought on this initially. But, I was not sure how we should
> implement preallocation in a non-extent based file. Using extents we can
> mark a set of blocks as unitialized, but how will we do this for
> non-extent based files ? If we do not have a way to mark blocks
> uninitialized, when someone will try to read from a preallocated block,
> it will return junk/stale data instead of zeroes.
If anything, the block-based preallocation could initialize all of the
data to zero. It would be slow, but it would still provide the correct
function and result in contiguous allocation.
Shaggy
--
David Kleikamp
IBM Linux Technology Center
-
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