Stan Hoeppner wrote: > On 8/14/2013 1:13 PM, Michael Maier wrote: >> Stan Hoeppner wrote: >>> If you keep growing until you consume the disk, you'll have ~100 >>> allocation groups. Typically you'd want to have no more than 4 AGs per >>> spindle. You already have 42 (or 45) which will tend to seek the disk >>> to death with many workloads, driving latency through the roof and >>> decreasing throughput substantially. Do you notice any performance >>> problems yet? >> >> What are expected rates for copying e.g. a 10GB file? It's a Seagate >> Barracuda 3000GB Model ST3000DM001 SATA connected to SATA 6 Gb/s chip. >> The source and the destination FS is LUKS crypted. About 3 GB usable RAM >> (cache), AMD FX-8350 processor @ max. 3800MHz. > > Too many variables really to hazard a guess. If you put a gun to my > head, I'd say strictly looking at the ingest rate of the Seagate, at a > little less than half capacity, writing about 1/3rd of the way down the > platters, optimum throughput should be 80-100 MB/s or so in the last 3 > AGs, if free space isn't too heavily fragmented. 96MB/s / 40GB-file ~ 130GB free space. -> good guess! [...] > With so many smallish AGs, so many grow ops, and this backup workload, > I'm curious as to what your free space map looks like. Would you mind > posting the output of the following command, if you can? > > $ xfs_db -r -c freesp <dev> after copying: from to extents blocks pct 1 1 193 193 0.00 2 3 31 72 0.00 4 7 10 60 0.00 8 15 8 94 0.00 16 31 9 210 0.00 32 63 14 631 0.00 64 127 20 1974 0.01 128 255 16 2838 0.01 256 511 12 4923 0.02 512 1023 13 10065 0.04 1024 2047 14 23417 0.10 2048 4095 22 58439 0.25 4096 8191 8 44159 0.19 8192 16383 1 8192 0.04 16384 32767 7 165001 0.71 32768 65535 6 228278 0.99 262144 524287 1 398328 1.72 1048576 2097151 2 3560198 15.39 2097152 4194303 1 3709535 16.04 4194304 7700480 2 14909432 64.47 Regards, Michael. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs