From: Yuto Ohnuki <ytohnuki@amazon.com>
To: Dave Chinner <dgc@kernel.org>
Cc: Carlos Maiolino <cem@kernel.org>,
"Darrick J . Wong" <djwong@kernel.org>,
<linux-xfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] xfs: check directory data block header padding in scrub
Date: Fri, 10 Apr 2026 18:26:58 +0100 [thread overview]
Message-ID: <adky4hw3YdX06wEF@c889f3b07a0a.ant.amazon.com> (raw)
In-Reply-To: <adbKxVodbqAdM9Ol@dread>
On Thu, Apr 09, 2026 at 07:38:13AM +1000, Dave Chinner wrote:
> This seems .... a bit of a hack.
>
> For simplicity, performance and long term maintenance of the code,
> we should zero the whole directory block header region
> unconditionally. This means we don't have to change the dir3 blk header
> initialisation code (except to remove the zeroing), we can remove
> the manual bestfree zeroing loop, all the padding (implicit and
> explicit) will be zeroed, and we know that any future
> changes to the dir header structure will automatically be
> initialised to zero....
>
> i.e.
> /* initialise the whole directory header region to zero */
> memset(bp->b_addr, 0, geo->data_entry_offset);
Thank you for the valuable feedback. I'll rework this patch
along these lines.
> You don't need endian conversion on a value of 0.
Understood. I'll fix this, same as the other patch.
> Why only update scrub? Why not add code that unconditionally
> sets the padding to 0 on directory data block writes? e.g. in
> xfs_dir3_data_write_verify() alongside the writing of the LSN into
> the header?
>
> That way any directory that is modified ends up having the padding
> zeroed at runtime with no additional cost, and so filesystems will
> slowly correct themselves over time without needing to run repair...
>
> -Dave.
> --
> Dave Chinner
> dgc@kernel.org
Good point, thanks again. I'm also looking into adding self-healing in
xfs_dir3_data_write_verify() and may split the changes into a series
for easier review.
Thanks,
Yuto
Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
prev parent reply other threads:[~2026-04-10 17:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-08 17:27 [PATCH v2] xfs: check directory data block header padding in scrub Yuto Ohnuki
2026-04-08 21:38 ` Dave Chinner
2026-04-10 17:26 ` Yuto Ohnuki [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=adky4hw3YdX06wEF@c889f3b07a0a.ant.amazon.com \
--to=ytohnuki@amazon.com \
--cc=cem@kernel.org \
--cc=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.