On Wed, Jul 7, 2021 at 4:30 AM Qu Wenruo [off-list ref] wrote:

On 2021/7/5 上午10:00, Qu Wenruo wrote:

quoted

This much smaller patchset can be fetched from github:
https://github.com/adam900710/linux/tree/subpage

And thanks him again for fixing up the small typos and style problem in
my old patches. Almost no patch is no untouched, really appreciate the
effort.

These patchset is targeted at v5.15 merge window.
There are 11 patches pending for a while, and not touched, thus they
should be pretty stable and safe.

While there are 4 new patches, two of them are straightforward small
fixes, the remaining 2 are a little scary as they reworked the core code
of compression.

But the rework should improve the readabilty thus make reviewing a
little easier (as least I hope so).

=== Current stage ===
The tests on x86 pass without new failure, and generic test group on
arm64 with 64K page size passes except known failure and defrag group.

For btrfs test group, all pass except compression/raid56/defrag.

For anyone who is interested in testing, please use btrfs-progs v5.12 to
avoid false alert at mkfs time.

=== Limitation ===
There are several limitations introduced just for subpage:
- No compressed write support
   Read is no problem, but compression write path has more things left to
   be modified.

Well, without proper testing just for compression read, it turns out
compression read path has more bugs than I thought.

The latest bug exposed during subpage compression write support is, the
add_rd_bio_pages().

Obviously it has tons of hard coded PAGE_SIZE, and can easily cause
ASSERT() for readers accounting.
As it added locked page without proper subpage::readers account updated.

For this case, I'm already crafting a proper fix for that.

But on the other hand, I'm not sure what's the proper way to introduce a
fix for v5.15 window.

Should I just disable readahead for compression read (which just needs
two lines to return 0 for subpage case in add_ra_bio_pages())?

Or should I add the proper fix into the patchset?

If this is going into 5.15 instead of 5.14, just add the proper fix
into this patch set. But if we want to land this in 5.14, I would
suggest disabling it for now and then having a separate patch set for
that.

You're already targeting 5.15 (though I kind of want this in 5.14...),
so I suggest going with adding the fix to the patch set.


-- 
真実はいつも一つ！/ Always, there's only one truth!