Re: xfs speculative preallocation -- fragmentation issue with sparse file handling?

[Mark Tinguely <tinguely@sgi.com>]

On 02/18/13 15:08, Brian Foster wrote:
> Hi guys,
>
> I was running a sanity check of my quota throttling stuff rebased
> against the updated speculative prealloc algorithm:
>
> a1e16c26 xfs: limit speculative prealloc size on sparse files
>
> ... and ran into an interesting behavior on my baseline test (quota
> disabled).
>
> The test I'm running is a concurrent write of 32 files (10GB each) via
> iozone (I'm not testing performance, just using it as a concurrent writer):
>
> iozone -w -c -e -i 0 -+n -r 4k -s 10g -t 32 -F /mnt/data/file{0..31}
>
> ... what I noticed is that from monitoring du during the test,
> speculative preallocation seemed to be ineffective. From further
> tracing, I observed that imap[0].br_blockcount in
> xfs_iomap_eof_prealloc_initial_size() was fairly consistently maxed out
> at around 32768 blocks (128MB).
>
> Without the aforementioned commit, preallocation occurs as expected and
> the files result in 7-9 extents after the test. With the commit, I'm in
> the 70s to 80s range of number of extents with a max extent size of
> 128MB. A couple examples of xfs_bmap output are appended to this
> message. It seems like initial fragmentation might be throwing the
> algorithm out of whack..?
>
> Brian

... the patched version increases in doubles

+	if (imap[0].br_startblock == HOLESTARTBLOCK)
+		return 0;

     vvvvvv
+	if (imap[0].br_blockcount <= (MAXEXTLEN >> 1))
+		return imap[0].br_blockcount;
     ^^^^^^

+	return XFS_B_TO_FSB(mp, XFS_ISIZE(ip));
+}

have you experimented without the middle if statement.
If I remember correctly when I reviewed the code, that should be moving
code closer to the original code; namely use the file size as the
preallocation value.

--Mark.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs