On 4/10/2012 3:43 PM, Stefan Ring wrote: > I don’t want to be expected to hand-tune every damn thing. You don't. >> $ mkfs.xfs -d agcount=3 /dev/[device] > With a nice and tidy fresh XFS file system, performance is indeed > impressive – about 16 sec for the same task that would take 2 min 25 > before. 9x improvement in your workload. First problem down. What was the runtime for EXT4 here? Less than 16 seconds? >>> and doesn’t seem to cope well with fragmented free space (which >>> is what this entire thread is really about), >> Did you retest fragmented freespace writes > Yes, I did this. It performed very well. Only slightly slower than on > a completely empty file system. 2nd problem down. So the concat is your solution, no? If not, what's still missing? BTW, concats don't have parity thus no RMW, so with the concat setup you should set 100% of the P400 cache to writes. The 25% you had for reads definitely helps RAID6 RMW, but yields no benefit for concat. Bump write cache to 100% and you'll gain a little more XFS concat performance. And if by chance there is some weird logic in the P400 firmware, dedicating 100% to write cache may magically blow the doors off. I'm guessing I'm not the only one here to have seen odd magical settings values like this at least once, though not necessarily with RAID cache. Even if not magical, in addition to increasing write cache size by 25%, you will also increase write cache bandwidth with your high allocation workload, as metadata free space lookups won't get cached by the controller. And given that sector write ordering is an apparent problem currently, having this extra size and bandwidth may put you over the top. -- Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
