On Wed, Dec 13, 2006 at 07:36:29AM -0600, Dave Kleikamp wrote: > 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. And posix_fallocate does that already ... Regards Suparna > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Suparna Bhattacharya (suparna@xxxxxxxxxx) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
