From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 1/4] xfs: online repair of directories
Date: Wed, 28 Feb 2024 09:16:38 -0800 [thread overview]
Message-ID: <Zd9qdpZU_er8nXdj@infradead.org> (raw)
In-Reply-To: <170900014471.939516.1582493895006132993.stgit@frogsfrogsfrogs>
On Mon, Feb 26, 2024 at 06:31:01PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
>
> If a directory looks like it's in bad shape, try to sift through the
> rubble to find whatever directory entries we can, scan the directory
> tree for the parent (if needed), stage the new directory contents in a
> temporary file and use the atomic extent swapping mechanism to commit
> the results in bulk. As a side effect of this patch, directory
> inactivation will be able to purge any leftover dir blocks.
I would have split xfs_inactive_dir and it's caller into a separate
prep patch, but if you want to keep that together that's probably
fine as it's completely unrelated functionality.
> + * Legacy Locking Issues
> + * ---------------------
> + *
> + * Prior to Linux 6.5, if /a, /a/b, and /c were all directories, the VFS would
> + * not take i_rwsem on /a/b for a "mv /a/b /c/" operation. This meant that
> + * only b's ILOCK protected b's dotdot update. b's IOLOCK was not taken,
> + * unlike every other dotdot update (link, remove, mkdir). If the repair code
> + * dropped the ILOCK, we it was required either to revalidate the dotdot entry
> + * or to use dirent hooks to capture updates from other threads.
> + */
How does this matter here?
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2024-02-28 17:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 2:18 [PATCHSET v29.4 09/13] xfs: online repair of directories Darrick J. Wong
2024-02-27 2:31 ` [PATCH 1/4] " Darrick J. Wong
2024-02-28 17:16 ` Christoph Hellwig [this message]
2024-02-28 18:22 ` Darrick J. Wong
2024-02-27 2:31 ` [PATCH 2/4] xfs: scan the filesystem to repair a directory dotdot entry Darrick J. Wong
2024-02-28 17:17 ` Christoph Hellwig
2024-02-27 2:31 ` [PATCH 3/4] xfs: online repair of parent pointers Darrick J. Wong
2024-02-28 17:17 ` Christoph Hellwig
2024-02-27 2:31 ` [PATCH 4/4] xfs: ask the dentry cache if it knows the parent of a directory Darrick J. Wong
2024-02-28 17:20 ` Christoph Hellwig
2024-02-28 18:24 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2023-12-31 19:31 [PATCHSET v29.0 22/28] xfs: online repair of directories Darrick J. Wong
2023-12-31 20:37 ` [PATCH 1/4] " Darrick J. Wong
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=Zd9qdpZU_er8nXdj@infradead.org \
--to=hch@infradead.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--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