On Tue, Apr 18, 2006 at 05:54:45PM -0400, Ming Zhang wrote:
> yes, xfs supports file hole.
>
> so about ext2, how to understand this in "understanding linux kernel"
>
> "the file system preallocate disk data blocks to regular files before
> they are actually used. thus, when the file increase in size, several
> blocks are already reserved at physically adjacent positions, reducing
> file fragmentation"
The key part here is "when the file increases in size". That only
happens when you do a write(), not when you do a seek().
So if you do a seek(some-very-large-value), the file will not increase
in size (on-disk). No space will be pre-allocated here. So that's why
you will always get 0 on read.
> and also XFS has a preallocation ioctl control that can pre-allocate
> some space for a file. so if that space is allocated, what will happen
> on read these space with no previous write happen? it will be
> troublesome for xfs to judge that space is preserved, but not used. that
> is 2 independent lookup services and overheads.
This is different from the standard hole thing, and needs to be
addressed by someone with proper knowledge of XFS. I tried to look at
the source code, and found this comment in xfs_vnodeops.c:
/*
* XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve
* file space.
* These calls do NOT zero the data space allocated to the file,
* nor do they change the file size.
*
* XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file
* space.
* These calls cause the new file data to be zeroed and the file
* size to be changed.
*/
It seems as soon as you do an XFS_IOC_ALLOCSP they will zero the data.
However, I don't understand the difference between RESVSP and ALLOCSP...
> i have a c program do this and so far return 0. but test can never mean
> 100%, right? only from xfs implementation logic can validate this.
Yes, and the fact that I think it has been said on list that XFS won't
return unwritten data.
Regards,
Iustin
|