Date:	Thu, 8 Feb 2007 14:22:31 +0530
From:	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>
To:	adilger@...sterfs.com
Subject: Re: Testing ext4 persistent preallocation patches for 64 bit features

On Wed, Feb 07, 2007 at 02:11:17PM -0700, Andreas Dilger wrote:
> On Feb 07, 2007  16:06 +0530, Suparna Bhattacharya wrote:
> > On Wed, Feb 07, 2007 at 12:25:50AM -0800, Mingming Cao wrote:
> > > - disable preallocation if the filesystem free blocks is under some low
> > > watermarks, to save space for near future real block allocation?
> > 
> > A policy decision like this is probably worth a discussion during today's call.
> > 
> > > - is de-preallocation something worth doing?
> 
> As discussed in the call - I don't think we can remove preallocations.
> The whole point of database preallocation is to guarantee that this space
> is available in the filesystem when writing into a file at random offsets
> (which would otherwise be sparse).
> 
> Similarly, persistent preallocation shouldn't be considered differently
> than an efficient way of doing zero filling of blocks.  At least that is
> my understanding...  Is this code implementing the "uninitialized extents"
> for databases (via explicit preallocation via fallocate/ioctl) so that
> they don't have to zero-fill large files, or is there also automatic
> preallocation of space to files (e.g. for O_APPEND files)?

You are right. There is no automatic preallocation of space being done
here. This code just implements the explicit (persistent) preallocation
of blocks via ioctl.

--
Regards,
Amit Arora
-
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

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux