XFS Preallocate using ALLOCSP

[Smit Shah]

On 6/16/09, Smit Shah <getsmit at gmail.com> wrote:
> On 6/16/09, Felix Blyakher <felixb at sgi.com> wrote:
>>
>> On Jun 16, 2009, at 12:28 PM, Smit Shah wrote:
>>
>>> Yeah rite what i meant to say was that posix_fallocate uses ftruncate
>>> which in turn just updates the i_size and then posix_fallocate zeros
>>> out the whole thing
>>
>> I didn't look at the libc implementation, but it seems
>> strange to use ftruncate here at all. Is it more efficient
>> to write zeros into a hole than appending to a file?
> I havent seen in detail but i had just scanned through the
> posix_fallocate code in libc sometime back and it seemed to be doing
> that but i can confirm that later.
>
Yeah it simply write's zero's, i had seen the ftruncate used in the
posix_fallocate implimentation and hence got confused. It is used when
the prealloc length is zero and total file size is less than offset
specified.
My bad.

>> [snip]
>>
>>> Just to see if preallocation using fallocate helps reducing the
>>> fragmentation and increases the throughput.  I guess it wll help
>>> reduce the fragmentation
>>
>> ... and as result read performance on such files.
>>
>>> but the write performance is going to suffer.
>>
>> It's not clear why it should. Not doing preallocation doesn't
>> mean that there is no inode updates with every write. Why
>> would extent conversion be more expensive that creating the
>> space (extent) and updating the inode size for every write?
>> It'd interesting to reproduce your results. Any details on
>> your tests and the iometer usage?
>
> Since fallocate uses the RESVSP cmd for xfs. And as given given for
> RESVSP in man page for xfsctl
> If the  XFS filesystem  is  configured to flag unwritten file extents,
> performance will be negatively affected when writing to preallocated
> space, since extra filesystem transactions are required to convert
> extent  flags  on  the  range  of  the  file  written.
>
>>
>> Thanks,
>> Felix
>>
>>
>