Subject: Re: disable preallocation
From: Ming Zhang <mingz@ele.uri.edu>
Reply-To: mingz@ele.uri.edu
To: David Chinner <dgc@sgi.com>
Cc: Iustin Pop <iusty@k1024.org>, linux-xfs@oss.sgi.com
In-Reply-To: <1145409269.8601.229.camel@localhost.localdomain>
References: <1145391567.8601.183.camel@localhost.localdomain>
	 <20060418214252.GA3300@lapi.hq.k1024.org>
	 <1145397286.8601.202.camel@localhost.localdomain>
	 <20060418223553.GB3300@lapi.hq.k1024.org>
	 <1145401592.8601.211.camel@localhost.localdomain>
	 <20060418232920.GC3300@lapi.hq.k1024.org>
	 <1145404885.8601.214.camel@localhost.localdomain>
	 <20060419000409.GD3300@lapi.hq.k1024.org>
	 <1145406846.8601.216.camel@localhost.localdomain>
	 <20060419005133.GF7574742@melbourne.sgi.com>
	 <1145409269.8601.229.camel@localhost.localdomain>
Content-Type: text/plain
Date: Tue, 18 Apr 2006 22:10:23 -0400
Message-Id: <1145412624.25396.8.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-xfs-bounce@oss.sgi.com
Errors-to: linux-xfs-bounce@oss.sgi.com
Precedence: bulk
Status: O
Content-Length: 2683
Lines: 71

i finished the reading on related section in ULK and i think i knew why
my wrong understanding is wrong now.

preallocation is not a persistent action that give the space to file
persistently. in fact, it is preserved to that file and if there are
write operations on that file, the prealloated space will possibly be
used. if nothing happen on that file, file closed, or truncated, that
preallocated is freed and maybe new preallocation will be given later.

so if there is no write on certain offset, but a seek over it, it will
form a hole in that area and no physical storage back it.

hope i have a right understanding now.

so a read will check inode and find out that no space available for that
file block (corresponding disk lba is 0), then it knows it met a hole.
could u tell me in which function in xfs code handle this?

thanks

Ming


On Tue, 2006-04-18 at 21:14 -0400, Ming Zhang wrote:
> On Wed, 2006-04-19 at 10:51 +1000, David Chinner wrote:
> > On Tue, Apr 18, 2006 at 08:34:05PM -0400, Ming Zhang wrote:
> > > 
> > > so u mean even there are preallocated space, file system should be able
> > > to know that is a hole, and that space is preallocated, not prewritten,
> > 
> > Preallocated space in XFS is not a hole - it is an unwritten extent.
> > That is different from a hole in that the extent has been physically
> > allocated, just marked as unwritten. Any attempt to read an unwritten
> > extent will return lots of zero, just like reading from a hole.
> 
> are preallocated space and hole are exclusive?
> 
> assume we do a preallocation from LBA 0 to 100 for a start-empty file,
> then write LBA 0-7 (assume 4KB block size), then write LBA 16-23.
> then about area lba 8-15
> 
> * it is a preallocated space,
> * it is also marked as unwritten,
> * is it a hole?
> 
> i guess when xfs get a read request, it will check some metadata and
> find out whether it is a hole, or/and a space allocated but unwritten,
> then return 0 without any disk io. am i correct? could u point out the
> related code that doing this?
> 
> if i do not use that ioctl to preallocate, will XFS do this
> automatically base on write pattern?
> 
> > 
> > > and it will return all 0? where is this posix standard i can check? thx
> > 
> > posix_fallocate()? Except it doesn't define what the contents of
> > the area allocated must contain, and is not implemented on Linux
> > in the filesystems. Instead, it is poorly emulated in glibc
> > by writing chunks of zeros to disk and hence it returns zeros
> > when the space is read before it is "written".
> 
> so this is why preallocate is recommended instead of doing a dd with
> zero out?
> 
> > 
> > Cheers,
> > 
> > Dave.
>