On Tue, Jul 31, 2018 at 10:12 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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. OK so why 33 AG's with xfsprogs 4.15, but 4 AG's with xfsprogs 4.17, when directed to the same thin LV? And also the difference in sunit and swidth? -- Chris Murphy -- 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
