On 7/31/18 11:38 PM, Chris Murphy wrote: > 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? > Did you build 4.17 with --disable-blkid? -Eric -- 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
