On 6/16/09, Smit Shah <getsmit@xxxxxxxxx> wrote:
> On 6/16/09, Felix Blyakher <felixb@xxxxxxx> 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
>>> 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.