Re: [PATCH] btrfs: move async csum generation out of experimental features

[David Sterba <dsterba@suse.cz>]

On Sat, Sep 05, 2026 at 07:51:42AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2026/9/5 02:30, David Sterba 写道:
> > On Thu, Sep 03, 2026 at 06:09:41PM +0930, Qu Wenruo wrote:
> >> @@ -4437,19 +4432,6 @@ void __cold close_ctree(struct btrfs_fs_info *fs_info)
> >>   	 */
> >>   	btrfs_flush_workqueue(fs_info->delalloc_workers);
> >>   
> >> -	/*
> >> -	 * We can have ordered extents getting their last reference dropped from
> >> -	 * the fs_info->workers queue because for async writes for data bios we
> >> -	 * queue a work for that queue, at btrfs_wq_submit_bio(), that runs
> >> -	 * run_one_async_done() which calls btrfs_bio_end_io() in case the bio
> >> -	 * has an error, and that later function can do the final
> >> -	 * btrfs_put_ordered_extent() on the ordered extent attached to the bio,
> >> -	 * which adds a delayed iput for the inode. So we must flush the queue
> >> -	 * so that we don't have delayed iputs after committing the current
> >> -	 * transaction below and stopping the cleaner and transaction kthreads.
> >> -	 */
> >> -	btrfs_flush_workqueue(fs_info->workers);
> > 
> > In the final fs closing sequence there's always some possible
> > interaction between the workers, but I don't think we need an explicit
> > flush anymore. The work offloaded to the system workers will be done
> > before we get here.
> 
> In fact, Daniel's commit ("btrfs: use bio::remaining for async 
> checksumming synchronization") changed the behavior back, and we may 
> need to be more cautious now.
> 
> Previously, the csum generation workload will never call endio in its 
> context, the only work it really bothers is just to wake the completion.
> 
> But now his commit changed to use bio_endio(), which means we can again 
> run the workload from csum generation workqueue.

Yeah, this kind of problems I'm expecting but haven't done a deeper
analysis to have concrete examples like that.

> In fact, I do not believe it's the proper timing to move async csum out 
> of experimental anymore, after his commit.
> 
> I'd prefer more the next merge window at least.

We can do that, the main part, otherwise any preparatory or cleanup work
can be done now, as usual.