On Thu, Jun 19, 2025 at 4:05 PM Jan Kara <jack@xxxxxxx> wrote: > > On Wed 18-06-25 15:37:20, Shakeel Butt wrote: > > > This is > > > beneficial for users who perform over-max reclaim while holding multiple > > > locks or other resources (especially resources related to file system > > > writeback). If a task needs any of these resources, it would otherwise > > > have to wait until the other task completes reclaim and releases the > > > resources. Postponing reclaim to the return-to-user path helps avoid this issue. > > > > > > # Background > > > > > > We have been encountering an hungtask issue for a long time. Specifically, > > > when a task holds the jbd2 handler > > > > Can you explain a bit more about jbd2 handler? Is it some global shared > > lock or a workqueue which can only run single thread at a time. > > Basically is there a way to get the current holder/owner of jbd2 handler > > programmatically? > > There's a typo in the original email :). It should be "jbd2 handle". And > that is just a reference to the currently running transaction in ext4 > filesystem. There can be always at most one running transaction in ext4 > filesystem and until the last reference is dropped it cannot commit. This > eventually (once the transaction reaches its maximum size) blocks all the > other modifications to the filesystem. So it is shared global resource > that's held by the process doing reclaim. > > Since there can be many holders of references to the currently running > transaction there's no easy way to iterate processes that are holding the > references... That being said ext4 sets current->journal_info when > acquiring a journal handle but other filesystems use this field for other > purposes so current->journal_info being non-NULL does not mean jbd2 handle > is held. Hi Jan, Thanks for your feedback and explanations. > > Honza > -- > Jan Kara <jack@xxxxxxxx> > SUSE Labs, CR
