From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs: enhance btrfs device path rename
Date: Wed, 25 Sep 2024 09:35:58 +0930 [thread overview]
Message-ID: <cover.1727222308.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Update the example of the first patch
Instead of using the special C program, just touch the soft link
to trigger the rescan.
- Add Link and reported-by tags for the first patch
- Fix a "weird" -> "wild" typo
This is really weird...
- Remove the debugging pr_info()
- Use safer strscpy() to replace strncpy()
- Use the shortcut version of conditional operator when possible
Fabian Vogt reported a very interesting case where we can use
"/proc/self/fd/3" to mount a btrfs, then that /proc name will remain as
the device path for the btrfs.
Sometimes udev scan can trigger a rename, and get a proper name back,
but if that doesn't win the race, we got the "/proc/self/fd/3" in the
mtab which makes no sense, since "/proc/self" is bounded to the current
process, no one is going to know where the real device is.
So to enhance the handling:
- Do proper path comparison to determine if we want to update device
path
Currently the path comparison is done by strcmp(), which will never
handle different hard nor soft links.
Instead go with path_equal() on the resolved paths, which is way more
reliable.
This should reduce the unnecessary path name updates in the first
place.
- Canonicalize the device path if it's not inside "/dev/"
If we pass a soft link which is not inside "/dev/", we just follow the
soft link and use the final destination instead.
It can be something like "/dev/dm-2", other than more readable LVM
names like "/dev/test/scratch1", but it's still way better than
"/proc/self/fd/3".
If the soft link itself is already inside "/dev/", then we can
directly use the path.
This is to allow fstest run properly without forced to use
"/dev/dm-*" instead of the "/dev/mapper/test-scratch1" as test
devices.
Otherwise fs tests will reject runs because it believe the btrfs
is mounted somewhere else.
Qu Wenruo (2):
btrfs: avoid unnecessary device path update for the same device
btrfs: canonicalize the device path before adding it
fs/btrfs/volumes.c | 107 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 105 insertions(+), 2 deletions(-)
--
2.46.1
next reply other threads:[~2024-09-25 0:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 0:05 Qu Wenruo [this message]
2024-09-25 0:05 ` [PATCH v2 1/2] btrfs: avoid unnecessary device path update for the same device Qu Wenruo
2024-10-02 14:14 ` Filipe Manana
2024-10-02 21:09 ` Qu Wenruo
2024-10-02 21:20 ` Filipe Manana
2024-09-25 0:06 ` [PATCH v2 2/2] btrfs: canonicalize the device path before adding it Qu Wenruo
2024-09-25 11:04 ` Filipe Manana
2024-09-30 5:26 ` Anand Jain
2024-09-30 5:31 ` Qu Wenruo
2024-09-30 12:40 ` Anand Jain
2024-09-30 21:42 ` Qu Wenruo
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=cover.1727222308.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@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 NNTP newsgroup(s).