On Fri, Oct 05 2018 at 7:27am -0400, Ilya Dryomov <idryomov@xxxxxxxxx> wrote: > On Fri, Oct 5, 2018 at 12:29 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > > > On Thu, Oct 04, 2018 at 01:33:12PM -0500, Eric Sandeen wrote: > > > On 10/4/18 12:58 PM, Ilya Dryomov wrote: > > > > rbd devices report the following geometry: > > > > > > > > $ blockdev --getss --getpbsz --getiomin --getioopt /dev/rbd0 > > > > 512 > > > > 512 > > > > 4194304 > > > > 4194304 > > > > dm-thinp does this as well. THis is from the thinp device created > > by tests/generic/459: > > > > 512 > > 4096 > > 65536 > > 65536 > > (adding Mike) > > ... and that 300M filesystem ends up with 8 AGs, when normally you get > 4 AGs for anything less than 4T. Is that really intended? > > AFAIK dm-thinp reports these values for the same exact reason as rbd: > we are passing up the information about the efficient I/O size. In the > case of dm-thinp, this is the thinp block size. If you put dm-thinp on > top of a RAID array, I suspect it would pass up the array's preferred > sizes, as long as they are a proper factor of the thinp block size. Right, see pool_io_hints() for all the logic thinp uses to consume block core's blk_stack_limits() provided limits.. thinp can override if the underlying limits are _not_ a factor of the thinp's blocksize. > The high agcount on dm-thinp has come up before and you suggested that > dm-thinp should report iomin == ioopt (i.e. sunit == swidth). If that > was the right fix back in 2014, mkfs.xfs must have regressed: > > https://marc.info/?l=linux-xfs&m=137783388617206&w=2 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fdfb4c8c1a9fc8dd8cf8eeb4e3ed83573b375285 Yeah, if we're getting larger AG count again, certainly seems like mkfs.xfs regressed. Mike
