On Thu, Jul 26, 2012, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> 10001 >> 20001 >> 30001 >> 40001 >> 10002 >> 20002 >> 30002 >> 40002 >> 10003 >> 20003 >> ... > > That's the problem you should have reported. I did, but then I got bashed for using RAID 5/6 and about the specifics of hardware and everything, which shouldn't even matter, but I let myself get dragged into this discussion. Anyway, in the meantime I had a closer look at the actual block trace, and it looks a bit different than the way I interpreted it at first. It sends runs of 30-50 writes with holes in them, like so: 2, 4-5, 7, 10-12, 14, 16-17 and so on. These holes seem to be caused by the free space fragmentation. Every once in a while -- somewhat frequently, after 30 or so blocks, as mentioned -- it switches to another allocation group. If these blocks were contiguous, then the elevator should be able to merge them, but the tiny holes make this impossible. So I guess there's nothing that can be substantially improved here. The frequent ag switches are a bit difficult for the controller to handle, but different controllers struggle under different work loads, and there's nothing that can be done about that. I noticed just today that the HP SmartArray controllers handle truly random writes better than the MegaRAID variety that I praised so much in my postings. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
