[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 14:42:35 -0700
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, 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=Cb1Z+MOLG3tpQJFAjeFe4RA7U1ZXJ3RxT8Cv/SIK6wA=; b=Da3kw5t6S4GTq3fr4eolhSYzXgrHXeu0ioGc6IErvct9oLLT8RxMoDDnoyqi6YDWSc WhwgcQvEz50Jvtc/tWhbUcIxAPwPbtKQysO4Pjl8+4uvdryOA54xGQLkyucQE25j379k oLvlN4AkidZVQ41K5ISJoTmaBDPGAJq/sAb/I=
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=PKlqGjgsZSVzEaATKTKH66VWmElUeRC9ZECuNzSp+KNgNKRTV4yn66uby7I12nGgAJ xvutK5+biCqKaXMwCffaJ3niCxU8BeoCn+R4p443VvzYgqZEc1JZf96Ua42fHXid5Fot 5VkvNtE5GZJLJeDAjtRMpvzPUyUYxeGfzd+H0=
In-reply-to: <B7C1A222-58C5-4858-80B4-F871BF088DB1@xxxxxxx>
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>
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.

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