[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bf893b28-f0a6-9863-0da1-4abdee24592d@163.com>
Date: Mon, 14 Oct 2024 13:51:30 +0800
From: Chi Zhiling <chizhiling@....com>
To: Dave Chinner <david@...morbit.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, cem@...nel.org,
linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
chizhiling <chizhiling@...inos.cn>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH] xfs_logprint: Fix super block buffer interpretation issue
On 2024/10/14 06:50, Dave Chinner wrote:
> On Sun, Oct 13, 2024 at 12:00:22PM +0800, Chi Zhiling wrote:
>> On 2024/10/13 06:10, Dave Chinner wrote:
>>> On Fri, Oct 11, 2024 at 11:54:08AM +0800, Chi Zhiling wrote:
>>>> On 2024/10/11 11:24, Darrick J. Wong wrote:
>>>>> On Fri, Oct 11, 2024 at 11:08:10AM +0800, Chi Zhiling wrote:
>>>>>> From: chizhiling<chizhiling@...inos.cn>
>>>>>>
>>>>>> When using xfs_logprint to interpret the buffer of the super block, the
>>>>>> icount will always be 6360863066640355328 (0x5846534200001000). This is
>>>>>> because the offset of icount is incorrect, causing xfs_logprint to
>>>>>> misinterpret the MAGIC number as icount.
>>>>>> This patch fixes the offset value of the SB counters in xfs_logprint.
>>>>>>
>>>>>> Before this patch:
>>>>>> icount: 6360863066640355328 ifree: 5242880 fdblks: 0 frext: 0
>>>>>>
>>>>>> After this patch:
>>>>>> icount: 10240 ifree: 4906 fdblks: 37 frext: 0
>>>>>>
>>>>>> Signed-off-by: chizhiling<chizhiling@...inos.cn>
>>>>>> ---
>>>>>> logprint/log_misc.c | 8 ++++----
>>>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/logprint/log_misc.c b/logprint/log_misc.c
>>>>>> index 8e86ac34..21da5b8b 100644
>>>>>> --- a/logprint/log_misc.c
>>>>>> +++ b/logprint/log_misc.c
>>>>>> @@ -288,13 +288,13 @@ xlog_print_trans_buffer(char **ptr, int len, int *i, int num_ops)
>>>>>> /*
>>>>>> * memmove because *ptr may not be 8-byte aligned
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>> This is important. I'll come back to it.
>>>
>>>>>> */
>>>>>> - memmove(&a, *ptr, sizeof(__be64));
>>>>>> - memmove(&b, *ptr+8, sizeof(__be64));
>>>>> How did this ever work?? This even looks wrong in "Release_1.0.0".
>>>>>
>>>> Yes, I was surprised when I find this issue
>>> I"ve never cared about these values when doing diagnosis because
>>> lazy-count means they aren't guaranteed to be correct except at
>>> unmount. At which point, the correct values are generally found
>>> in the superblock. IOWs, the values are largely meaningless whether
>>> they are correct or not, so nobody has really cared enough about
>>> this to bother fixing it...
>> Because I got a log which shows that the fdblocks was (-8), it caused
>> the filesystem to fail mounting again. 'SB summary counter sanity check failed'
> What kernel? Because AFAIK, that was fixed in commit 58f880711f2b
> ("xfs: make sure sb_fdblocks is non-negative") in 6.10...
It's a 4.19 kernel. As you said, the fdblocks is meaningless, I think
that patch (commit 58f880711f2b) is enough to fix the issue.
Thank you for your reminding.
chi
Powered by blists - more mailing lists