What were you trying to do that didn't work?

While testing RHEL-58253 on RHEL 10, I tried to create a filesystem with small agsize/large agcount. While the problem in RHEL-58253 does not appear, I get instead the error message "Log size must be at least 64MB." and the usage screen, as if a wrong option had been specified.

What is the impact of this issue to you?

There are several issues with this behavior. The main impact on me is that there can be an existing filesystem with such parameters and it will not be possible to recreate it with the same parameters. I maintain a disaster recovery tool called ReaR, which strives at recreating a system with a storage layout as close as possible to the original layout, including XFS parameters. This error will result in a failure during recovery of the system from backup, which will be very frustrating for the user (although workarounds are possible). The geometry that leads to this is fortunately uncommon, but can be produced on older systems using the agsize parameter, or by creating a very small XFS filesystem and then growing it (see also RHEL-7960), which is a common deployment method of OS images. It is true that creating such a filesystem on RHEL 9 produces the warning like

Filesystem should be larger than 300MB.
Log size should be at least 64MB.
Support for filesystems like this one is deprecated and they will not be supported in future releases.

(example:

# lvcreate -y --thinpool lvol1 -V 50331648b -n lv_srv  vg
  Logical volume "lv_srv" created.
# mkfs.xfs -f /dev/vg/lv_srv
mkfs.xfs: small data volume, ignoring data volume stripe unit 128 and stripe width 128
Filesystem should be larger than 300MB.
Log size should be at least 64MB.
Support for filesystems like this one is deprecated and they will not be supported in future releases.
meta-data=/dev/vg/lv_srv         isize=512    agcount=2, agsize=6144 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=0
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=0
data     =                       bsize=4096   blocks=12288, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=1368, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
Discarding blocks...Done.

)
so problems when upgrading such a system are kind of expected, but this warning does not appear in older systems (I tried RHEL 9.2 EUS and RHEL 8.10) and it seems perfectly legal to me to install a RHEL 8.10 or 9.2 system like this and upgrade it to RHEL 10 (possibly with an intermediate upgrade to a current RHEL 9), which will lead to a problematic system without any warning displayed. (Unless the Leapp in-place upgrade tooling warns about problems with a major version upgrade of such a system (I have not checked), such a feature (actor) would be really nice to have.)
The other problem is that the behavior is unintuitive and undocumented. It can be triggered without providing any log size (-l size=...) at all. According to the manual page, "If the log is contained within the data section and size isn't specified, mkfs.xfs will try to select a suitable log size depending on the size of the filesystem." I have not specified a -l size=..., so why is mkfs.xfs complaining instead of selecting a suitable log size itself? I suspect that there is a limitation that the whole log must fit into one AG, which is confirmed by specifying a larger log size manually:

mkfs.xfs -f -i size=512 -d agsize=7680b -s size=512 -i attr=2 -i projid32bit=1 -m crc=1 -m finobt=1 -b size=4096 -i maxpct=25 -d sunit=128 -d swidth=128 -l version=2 -l lazy-count=1 -l size=16384b -n size=4096 -n version=2 -r extsize=4096 /dev/mapper/vg-lv_log

(note -d agsize=7680b -l size=16384b), I get the error:
"internal log size 16384 too large, must be less than 7668". This limitation is however not documented at all in the manual page (at least neither in the description of agsize nor in the description of log size) and also the error message "Log size must be at least 64MB." does not say at all that the small log size got chosen because of the small agsize.
In fact the manual page contains misleading information, as the description of agsize reads "This value must be a multiple of the filesystem block size, and must be at least 16MiB". How is the minimal size 16MiB if the log must fit into one AG and it must be at least 64 MB? Sure, the log can be external, but how often is that used? It would be nice to at least mention this limitation. The description of the log size option is also misleading:

The overriding minimum value for
size is 512 blocks. With some combinations of
filesystem block size, inode size, and directory
block size, the minimum log size is larger than 512
blocks.

The log should be at least 64MB in size.

How can the minimum size be 512 blocks if the minimum size is at the same time 64 MB and the maximum block size is 64 KiB? (further limited by page size in fact.) Also, is that MB or MiB? Looks like there is some confusion of units in the manual page.

Please provide the package NVR for which the bug is seen:

xfsprogs-6.5.0-4.el10.x86_64

How reproducible is this bug?:

well reproducible with the right parameters, analogously to RHEL-58253

Steps to reproduce

1.  pvcreate -f /dev/vdb
2.  vgcreate vg /dev/vdb
3.  lvcreate --type thin-pool -l 95%FREE -n lvol1 vg
4. lvcreate --type thin -V 90248839168b --thinpool lvol1 vg -n lv_log
5. mkfs.xfs -f -i size=512 -d agcount=2869 -s size=512 -i attr=2 -i projid32bit=1 -m crc=1 -m finobt=1 -b size=4096 -i maxpct=25 -d sunit=128 -d swidth=128 -l version=2 -l sunit=128 -l lazy-count=1 -n size=4096 -n version=2 -r extsize=4096 /dev/mapper/vg-lv_log

Expected results

log size gets chosen properly

Actual results

Error Log size must be at least 64MB., usage displayed, exit status 1, see above.