On 5/23/22 1:43 AM, Jens Axboe wrote:
On 5/22/22 11:07 AM, Coly Li wrote:
Hi Jens,
The bcache has 4 patches for Linux v5.19 merge window, all from me.
- The first 2 patches are code clean up and potential bug fixes for
multi- threaded btree nodes check (for cache device) and dirty sectors
counting (for backing device), although no report from mailing list for
them, it is good to have the fixes.
- The 3rd patch removes incremental dirty sectors counting because it
is conflicted with multithreaded dirty sectors counting and the latter
one is 10x times faster.
- The last patch fixes a journal no-space deadlock during cache device
registration, it always reserves one journal bucket and only uses it
in registration time, so the no-spance condition won't happen anymore.
There are still 2 fixes are still under the long time I/O pressure
testing, once they are accomplished, I will submit to you in later
RC cycles.
Please take them, and thanks in advance.
It's late for sending in that stuff, now I have to do a round 2 or
your patches would get zero time in linux-next. Please send patches
a week in advance at least, not on the day of release...
Hi Jens,
This time the situation was awkward, indeed I didn't expect I can submit
the fix in this merge window, but just around 1 week before I found the
difficult was from influence by other depending issues. After fixed all
of them and do I/O pressure testing for 24x2 hours, it comes to such
close day to the merge window.
My confusion was, it was very close to the merge window so maybe I
should submit them in next merge window (5.20), but this series were bug
fixes which should go into mainline earlier. It seems neither option was
proper, so I chose the first one...
Could you give me a hint, what is the proper way that I should do for
such situation? Then I will try to follow that and avoid adding more
workload to you.
Thanks in advance.
Coly Li
