From: Stephen Zhang <starzhangzsd@gmail.com>
To: linux-xfs@vger.kernel.org
Subject: Potential issue with a directory block
Date: Fri, 29 Mar 2024 10:55:29 +0800 [thread overview]
Message-ID: <CANubcdXY-otymMxDpzbdy1q5osnruNeU7L-b_+eeNo682U4p+Q@mail.gmail.com> (raw)
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?
Hope my naive question doesn't contaminate your timeline.
Thanks,
Stephen.
next reply other threads:[~2024-03-29 2:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 2:55 Stephen Zhang [this message]
2024-04-01 10:49 ` Potential issue with a directory block Dave Chinner
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=CANubcdXY-otymMxDpzbdy1q5osnruNeU7L-b_+eeNo682U4p+Q@mail.gmail.com \
--to=starzhangzsd@gmail.com \
--cc=linux-xfs@vger.kernel.org \
/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).