<div dir="ltr">I meant sync not fsync(O_SYNC flag).<div><br></div><div>My main question is why there is better throughput when I make the agsize smaller?</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Oct 30, 2013 at 5:59 AM, Matthias Schniedermeyer <span dir="ltr"><<a href="mailto:ms@citd.de" target="_blank">ms@citd.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 29.10.2013 18:10, K T wrote:<br>
> Hi,<br>
><br>
> I have a 1 TB SATA disk(WD1003FBYX) with XFS. In my tests, I preallocate a<br>
> bunch of 10GB files and write data to the files one at a time. I have<br>
> observed that the default mkfs setting(4 AGs) gives very low throughput.<br>
> When I reformat the disk with a agsize of 256mb(agcount=3726), I see better<br>
> throughput. I thought with a bigger agsize, the files will be made of fewer<br>
> extents and hence perform better(due to lesser entries in the extent map<br>
> getting updated). But, according to my tests, the opposite seems to be<br>
> true. Can you please explain why this the case? Am I missing something?<br>
><br>
> My test parameters:<br>
><br>
> mkfs.xfs -f /dev/sdbf1<br>
> mount  -o inode64 /dev/sdbf1 /mnt/test<br>
> fallocate -l 10G fname<br>
> dd if=/dev/zero of=fname bs=2M count=64 oflag=direct,sync conv=notrunc seek=0<br>
<br>
</div>I get the same bad performance with your dd statement.<br>
<br>
fallocate -l 10G fname<br>
time dd if=/dev/zero of=fname bs=2M count=64 oflag=direct,sync conv=notrunc seek=0<br>
<div class="im">64+0 records in<br>
64+0 records out<br>
</div>134217728 bytes (134 MB) copied, 4,24088 s, 31,6 MB/s<br>
<br>
After pondering the really hard to read dd-man-page.<br>
Sync is for 'synchronized' I/O. aka REALLY BAD PERFORMANCE. And i assume<br>
you don't really that.<br>
<br>
I think what you meant is fsync. (a.k.a. File (and Metadata) has hit<br>
stable-storage before dd exits).<br>
That is: conv=fsync<br>
<br>
So:<br>
time dd if=/dev/zero of=fname bs=2M count=64 oflag=direct conv=notrunc,fsync seek=0<br>
<div class="im">64+0 records in<br>
64+0 records out<br>
</div>134217728 bytes (134 MB) copied, 1,44088 s, 93,2 MB/s<br>
<br>
That gets much better performance, and in my case it can't get any<br>
better because the HDD (and encryption) just can't go any faster.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
<br>
Matthias<br>
</font></span></blockquote></div><br></div>