[Top] [All Lists]

Re: XFS Preallocate using ALLOCSP

To: Smit Shah <getsmit@xxxxxxxxx>
Subject: Re: XFS Preallocate using ALLOCSP
From: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 16 Jun 2009 12:41:45 -0500
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <8770d98c0906161028j1cc5cbadl49d30092fddf3dbe@xxxxxxxxxxxxxx>
References: <24042506.post@xxxxxxxxxxxxxxx> <4A3712BF.7030101@xxxxxxxxxxx> <8770d98c0906152344p185533a9rc144a5667d13d2de@xxxxxxxxxxxxxx> <4A37B744.9030301@xxxxxxxxxxx> <0B774481-16A5-42FC-89C3-91096E59E861@xxxxxxx> <8770d98c0906161028j1cc5cbadl49d30092fddf3dbe@xxxxxxxxxxxxxx>

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?


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?


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