On Tue, Jul 31, 2018 at 07:32:50PM -0600, Chris Murphy wrote: > This seems suboptimal. It's actually a very useful optimisation to make on thin devices. > Basically this is a 750G thin volume. I don't > have a plain partition on a device handy to try this out but I'm > pretty certain the default is 4 AG's in that case, so I'm confused why > by default 33 AGs are created on a thin volume. The LVM volume group > is on a dmcrypt PV. It's a thin volume, therefore it advertises an optimal IO size and alignment setting (i.e. the thin volume allocation chunk size). Hence mkfs.xfs treats it as a "multi-disk device" and sets up alignment and AG count appropriately. This is actually the right optimisation to make for sparse devices - more AGs increase filesystem concurrency but we normally restrict it on single spindles because each AG adds more seeks into typical workloads and slows them down. However, the thin volume already adds that penalty to the storage stack for us because they don't have a linear LBA-to-physical location characteristic. Hence we can increase filesystem concurrency without addition performance penalties being incurred. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
