Re: [PATCH 00/10] btrfs: improve error reporting for log tree replay

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2025/7/22 19:34, Filipe Manana 写道:
> On Tue, Jul 22, 2025 at 1:16 AM Qu Wenruo <wqu@suse.com> wrote:
>>
>>
>>
>> 在 2025/7/22 02:46, fdmanana@kernel.org 写道:
>>> From: Filipe Manana <fdmanana@suse.com>
>>>
>>> Most errors that happen during log replay or destroying a log tree are hard
>>> to figure out where they come from, since typically deep in the call chain
>>> of log tree walking we return errors and propagate them up to the caller of
>>> the main log tree walk function, which then aborts the transaction or turns
>>> the filesystem into error state (btrfs_handle_fs_error()). This means any
>>> stack trace and message provided by a transaction abort or turning fs into
>>> error state, doesn't provide information where exactly in the deep call
>>> chain the error comes from.
>>>
>>> These changes mostly make transacton aborts and btrfs_handle_fs_error()
>>> calls where errors happen, so that we get much more useful information
>>> which sometimes is enough to understand issues. The rest are just some
>>> cleanups.
>>
>> Reviewed-by: Qu Wenruo <wqu@suse.com>
>>
>> Although I believe we may further enhance the output by dumping the log
>> tree when replay_one_buffer() function failed.
>>
>> Especially considering we don't have a simple way to dump the log tree
>> for a subvolume (always needs to go through the log tree root, then into
>> the log tree of a subvolume).
> 
> Dumping the log tree alone is not as useful as you might think.
> 
> Unless there's an actual IO error due to some extent buffer not
> getting persisted, problems during log replay happen because:
> 
> 1) There are items we didn't log - you can only figure that out by
> checking the subvolume tree as well;
> 
> 2) There are items we logged but should have been removed from a log
> tree after events such as unlinks and renames for example - again,
> that can figured out only by checking the subvolume tree as well;
> 
> So most, if not all problems during log replay, that I remember ever
> fixing, and there were lots of them, boiled down to that.
> And most times we also need to have an idea of what file/dir
> operations happened besides checking the log and subvolume trees.
> 
> Also dumping an entire log tree is too much, as it can reach 3 levels
> (root at level 2) during the lifetime of a transaction.
> 
> There are other things I want to do on top of these changes, but
> dumping an entire log tree is not of them.

My bad, since we're at replay_one_buffer() the more sane one is to dump 
that log tree leaf.

And the subvolume leaf is also at reach, e.g. dump path->nodes[0] if 
there is an error and we have path->nodes[0] populated inside various 
replay_*() functions.

Thanks,
Qu

> 
> 
>>
>> Thanks,
>> Qu
>>
>>
>>>
>>> Filipe Manana (10):
>>>     btrfs: error on missing block group when unaccounting log tree extent buffers
>>>     btrfs: abort transaction on specific error places when walking log tree
>>>     btrfs: abort transaction in the process_one_buffer() log tree walk callback
>>>     btrfs: use local variable for the transaction handle in replay_one_buffer()
>>>     btrfs: return real error from read_alloc_one_name() in drop_one_dir_item()
>>>     btrfs: abort transaction where errors happen during log tree replay
>>>     btrfs: exit early when replaying hole file extent item from a log tree
>>>     btrfs: process inline extent earlier in replay_one_extent()
>>>     btrfs: use local key variable to pass arguments in replay_one_extent()
>>>     btrfs: collapse unaccount_log_buffer() into clean_log_buffer()
>>>
>>>    fs/btrfs/tree-log.c | 659 +++++++++++++++++++++++++++-----------------
>>>    1 file changed, 401 insertions(+), 258 deletions(-)
>>>
>>
>>
>