| Message ID | cover.1740542375.git.wqu@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | btrfs: support 2k block size for debug builds | expand |
On Wed, Feb 26, 2025 at 02:40:19PM +1030, Qu Wenruo wrote: > [REPO] > This series depends on the existing subpage related patches to pass most > fstests, so please fetch it from the following repo: > > https://github.com/adam900710/linux/tree/2k_blocksize > > Of course, one can still apply those involved patches on for-next > branch, but running such btrfs with 2K block size are going to hit most > if not all bugs fixed in the subpage branch. > > > >From day 1 btrfs only supports block size as small as 4K, this means on > the most common architecture, x86_64, has no way to test subpage block > size support. > > That's why most of my tests are done on aarch64 nowadays, but such > limited availability is not a good thing for test coverage. > The situation can be improved if we have larger data folios support, but > that is another huge feature, and we're not sure how far away we really > are. > > So here we go with a much simpler solution, just lowering the minimal > block size to 2K for debug builds. > > The support has quite some limitations, but should not be a big deal > because we're not pushing this support to end users: > > - No 2K node size support > This is the limit by mkfs, not by the kernel. > But it's still a problem as this means we can not test the metadata > subpage routine. > > - No mixed block groups support > As there is no 2K node size support from mkfs.btrfs. > > - Very limited inline data extents support > No inline extent size can go beyond 2K, this affects both regular > files and symlinks/xattrs. > > Quite some inline related test will fail due to this. > > This allows x86_64 to utilize the subpage block size routine, and in > fact it already exposed a bug that is not reproducible on aarch64. > (I believe it's related to the page reclaim behavior) > > The first patch is to fix the deadlock that is only reproducible on > x86_64. > The second one is to fix btrfs-check errors that non-compressed block > sized inline extents are reported as an error. > The final one enables the 2K block size support for DEBUG builds. > > For now there are around a dozen of failed test cases, mostly related to > inline and mkfs limitations, but this is good enough as the beginning of > subpage testing on x86_64. > > Qu Wenruo (3): > btrfs: subpage: do not hold subpage spin lock when clearing folio > writeback > btrfs: properly limit inline data extent according to block size > btrfs: allow debug builds to accept 2K block size Reviewed-by: David Sterba <dsterba@suse.com>
[REPO] This series depends on the existing subpage related patches to pass most fstests, so please fetch it from the following repo: https://github.com/adam900710/linux/tree/2k_blocksize Of course, one can still apply those involved patches on for-next branch, but running such btrfs with 2K block size are going to hit most if not all bugs fixed in the subpage branch. From day 1 btrfs only supports block size as small as 4K, this means on the most common architecture, x86_64, has no way to test subpage block size support. That's why most of my tests are done on aarch64 nowadays, but such limited availability is not a good thing for test coverage. The situation can be improved if we have larger data folios support, but that is another huge feature, and we're not sure how far away we really are. So here we go with a much simpler solution, just lowering the minimal block size to 2K for debug builds. The support has quite some limitations, but should not be a big deal because we're not pushing this support to end users: - No 2K node size support This is the limit by mkfs, not by the kernel. But it's still a problem as this means we can not test the metadata subpage routine. - No mixed block groups support As there is no 2K node size support from mkfs.btrfs. - Very limited inline data extents support No inline extent size can go beyond 2K, this affects both regular files and symlinks/xattrs. Quite some inline related test will fail due to this. This allows x86_64 to utilize the subpage block size routine, and in fact it already exposed a bug that is not reproducible on aarch64. (I believe it's related to the page reclaim behavior) The first patch is to fix the deadlock that is only reproducible on x86_64. The second one is to fix btrfs-check errors that non-compressed block sized inline extents are reported as an error. The final one enables the 2K block size support for DEBUG builds. For now there are around a dozen of failed test cases, mostly related to inline and mkfs limitations, but this is good enough as the beginning of subpage testing on x86_64. Qu Wenruo (3): btrfs: subpage: do not hold subpage spin lock when clearing folio writeback btrfs: properly limit inline data extent according to block size btrfs: allow debug builds to accept 2K block size fs/btrfs/disk-io.c | 12 +++++++++--- fs/btrfs/fs.h | 12 ++++++++++++ fs/btrfs/inode.c | 14 +++++++++++++- fs/btrfs/subpage.c | 10 ++++++++-- fs/btrfs/subpage.h | 2 +- fs/btrfs/sysfs.c | 3 ++- 6 files changed, 45 insertions(+), 8 deletions(-)