[Top] [All Lists]

Re: XFS Preallocate using ALLOCSP

To: Felix Blyakher <felixb@xxxxxxx>
Subject: Re: XFS Preallocate using ALLOCSP
From: Smit Shah <getsmit@xxxxxxxxx>
Date: Tue, 16 Jun 2009 15:19:12 -0700
Cc: linux-xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U0OwuW75xrj/07DYLnxSfCUarc5Pn/OeA26ihClD1NY=; b=axj8WIw7Jt4uh0DMRaAjN1SSNcnjJxqto5kZRSo+yRxlHxSO6HrMsojG8BFgEwXi8/ OWWPyLQAEtNvpR1fBu58HKoYyvbRfbiKEEolu7BXkmv0W+bh38QE5qpS9BleET4WHCFX BuE5UP1+YeWEKHnSipMxbOLgttGg/IXvIKjm4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aMC2GNAkmXxWcWcLhTauMQldfT8mLKgeZUPMGDCTgfXMSpQWIti2+WgmXwpXZPuX/f M7ltwUFQP7als+saM6gh1lxl9bfKitVsWEUfopCAweVm3FjYI9Ewe3CVt9MZhdr3o7sU 63tf2n03Aq0t5YEfFBskyq+Ovi+4MRMFHXJXI=
In-reply-to: <8770d98c0906161442t634467bxe8b0f5c32b49502e@xxxxxxxxxxxxxx>
References: <24042506.post@xxxxxxxxxxxxxxx> <4A3712BF.7030101@xxxxxxxxxxx> <8770d98c0906152344p185533a9rc144a5667d13d2de@xxxxxxxxxxxxxx> <4A37B744.9030301@xxxxxxxxxxx> <0B774481-16A5-42FC-89C3-91096E59E861@xxxxxxx> <8770d98c0906161028j1cc5cbadl49d30092fddf3dbe@xxxxxxxxxxxxxx> <B7C1A222-58C5-4858-80B4-F871BF088DB1@xxxxxxx> <8770d98c0906161442t634467bxe8b0f5c32b49502e@xxxxxxxxxxxxxx>
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
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

<Prev in Thread] Current Thread [Next in Thread>