From: Dave Chinner <david@fromorbit.com>
To: Stephen Zhang <starzhangzsd@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Potential issue with a directory block
Date: Mon, 1 Apr 2024 21:49:53 +1100 [thread overview]
Message-ID: <ZgqRUeuKnLDGxS+i@dread.disaster.area> (raw)
In-Reply-To: <CANubcdXY-otymMxDpzbdy1q5osnruNeU7L-b_+eeNo682U4p+Q@mail.gmail.com>
On Fri, Mar 29, 2024 at 10:55:29AM +0800, Stephen Zhang wrote:
> Hi all,
>
> It's all about the commit 09654ed8a18c ("xfs: check sb_meta_uuid for
> dabuf buffer recovery").
>
> IIUC, any XFS buffer will be in an internally consistent state
> regardless of whether any other buffer is replaying to it.
>
> Specifically, for a buffer like:
>
> ...
> bleaf[0].hashval = 0x2e
> bleaf[0].address = 0x8
> bleaf[1].hashval = 0x172e
> bleaf[1].address = 0xa
> bleaf[2].hashval = 0x4eccc517
> bleaf[2].address = 0x36
> bleaf[3].hashval = 0x4eccc519
> bleaf[3].address = 0x2a
> bleaf[4].hashval = 0x4eccc51a
> bleaf[4].address = 0x24
> bleaf[5].hashval = 0x4eccc51b
> bleaf[5].address = 0x1e
> bleaf[6].hashval = 0x4eccc51e
> bleaf[6].address = 0xc
> bleaf[7].hashval = 0x9133c702
> bleaf[7].address = 0x68
> bleaf[8].hashval = 0x9133c704
> bleaf[8].address = 0x52
> bleaf[9].hashval = 0x9133c705
> bleaf[9].address = 0
> bleaf[10].hashval = 0x9133c706
> bleaf[10].address = 0x3c
> bleaf[11].hashval = 0x9133c707
> bleaf[11].address = 0
> btail.count = 12
> btail.stale = 2
>
> and then If we skip a buffer replay during log recovery, the buffer
> will still be in an internally consistent state. This implies that the
> 'stale' or 'count' will be consistent with the real count in the
> block, meaning it won't trigger the check in xfs_dir3_leaf_check_int.
>
> but the commit 09654ed8a18c ("xfs: check sb_meta_uuid for dabuf buffer
> recovery") states that in some scenarios, IIUC, if we skip a buffer
> replay during log recovery, the buffer will not be in an internally
> consistent state.
>
> What could cause this inconsistency? Are there any potential issues
> with the directory block?
Original state: count = 12, stale = 2
Change A: adds entry @ 12
count = 13, stale = 2
Change B: removes entry 4
count = 13, stale = 3
Change C; adds entry @ 9
count = 13, stale = 2
So at the end of recovering these individual changes, we have stale
entries at 4 and 11.
Now let's fail to replay Change B. What's the final state when we
replay only A + C over the original buffer? Is it internally
consistent?
However, log recovery should never allow this "silently fail to
recover intermediate change" situation to occur - if it can't
recover change B, it must abort recovery immediately and never
attempt to recover change C....
-Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2024-04-01 10:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 2:55 Potential issue with a directory block Stephen Zhang
2024-04-01 10:49 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZgqRUeuKnLDGxS+i@dread.disaster.area \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=starzhangzsd@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).