Re: fstest failure due to filesystem size for 16k, 32k and 64k FSB

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Jan 30, 2024 at 02:18:01PM +0100, Pankaj Raghav wrote:
> As I pointed out in my previous thread [1], there are some testcases
> in fstests that are failing for FSB 16k, 32k and 64k due to the filesystem
> **size** under test. These are failures **upstream** and not due to the ongoing
> LBS work.
> 
> fstests creates a lot of tiny filesystems to perform some tests. Even though
> the minimum fs size allowed to create XFS filesystem is 300 MB, we have special
> condition in mkfs to allow smaller filesystems for fstest[2] (This took some time
> to figure out as I was splitting my hair how fstest is able to create XFS on top of
> 25MB images).
> 
> The problem comes when we have FSB 16k, 32k and 64k. As we will
> require more log space when we have this feature enabled, some test cases are failing
> with the following error message:
> 
> max log size XXX smaller than min log size YYY, filesystem is too small
> 
> Most test cases run without this error message with **rmapbt disabled** for 16k and 64k (see
> the test matrix below).
> 
> What should be the approach to solve this issue? 2 options that I had in my mind:
> 
> 1. Similar to [2], we could add a small hack in mkfs xfs to ignore the log space
> requirement while running fstests for these profiles.
> 
> 2. Increase the size of filesystem under test to accommodate these profiles. It could
> even be a conditional increase in filesystem size if the FSB > 16k to reduce the impact
> on existing FS test time for 4k FSB.
> 
> Let me know what would be the best way to move forward.
> 
> Here are the results:
> 
> Test environment:
> kernel Release: 6.8.0-rc1
> xfsprogs: 6.5.0
> Architecture: aarch64
> Page size: 64k
> 
> Test matrix:
> 
> | Test        | 32k rmapbt=0 | 32k rmapbt=1 | 64k rmapbt=0 | 64k rmapbt=1 |
> | --------    | ---------    | ---------    | ---------    | ---------    |
> | generic/042 |     fail     |     fail     |     fail     |     fail     |
> | generic/081 |     fail     |     fail     |     pass     |     fail     |
> | generic/108 |     fail     |     fail     |     pass     |     fail     |
> | generic/455 |     fail     |     fail     |     pass     |     fail     |
> | generic/457 |     fail     |     fail     |     pass     |     fail     |
> | generic/482 |     fail     |     fail     |     pass     |     fail     |
> | generic/704 |     fail     |     fail     |     pass     |     fail     |
> | generic/730 |     fail     |     fail     |     pass     |     fail     |
> | generic/731 |     fail     |     fail     |     pass     |     fail     |
> | shared/298  |     pass     |     pass     |     pass     |     fail     |

I noticed test failures on these tests when running djwong-wtf:
generic/042
generic/081
generic/108
generic/219
generic/305
generic/326
generic/562
generic/704
xfs/093
xfs/113
xfs/161
xfs/262
xfs/508
xfs/604
xfs/709

Still sorting through all of them, but a large portion of them are the
same failure to format due to minimum log size constraints.  I'd bump
them up to ~500M (or whatever makes them work) since upstream doesn't
really support small filesystems anymore.

--D

> 
> 16k fails only on generic/042 for both rmapbt=0 and rmapbt=1
> 
> 
> [1] https://lore.kernel.org/all/7964c404-bc9d-47ef-97f1-aaaba7d7aee9@samsung.com/
> [2] xfsprogs commit: 6e0ed3d19c54603f0f7d628ea04b550151d8a262
> -- 
> Regards,
> Pankaj
>