btrfs: support 2k block size for debug builds
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 1 replyIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | btrfs: subpage: do not hold subpage spin lock when clearing folio writebackfs/ | +8 | 0 replies | |
| 2/3 | btrfs: properly limit inline data extent according to block sizefs/ | +13 | 0 replies | |
| 3/3 | btrfs: allow debug builds to accept 2K block sizefs/ fs/ fs/ +1 more | +24 | 0 replies |
Reviews trailers per patch
None of the 3 patches has a Reviewed-by or Acked-by of their own; the series has one for all of them.
| Patch | David Sterba |
|---|---|
| Series | R-b |
| 1/3 | |
| 2/3 | |
| 3/3 |
Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.
Cover letter [PATCH 0/3] btrfs: support 2k block size for debug builds
[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(-)
Signature · 1 line
2.48.1