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@xxxxxxxxxxx/ > [2] xfsprogs commit: 6e0ed3d19c54603f0f7d628ea04b550151d8a262 > -- > Regards, > Pankaj >
