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.
|