From: Boris Burkov <boris@bur.io>
To: David Sterba <dsterba@suse.cz>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 2/2] btrfs-progs: add udev rule to forget removed device
Date: Thu, 29 Feb 2024 12:34:09 -0800 [thread overview]
Message-ID: <20240229203409.GA1754735@zen.localdomain> (raw)
In-Reply-To: <20240229195339.GF2604@twin.jikos.cz>
On Thu, Feb 29, 2024 at 08:53:39PM +0100, David Sterba wrote:
> On Thu, Feb 29, 2024 at 10:36:55AM -0800, Boris Burkov wrote:
> > Now that btrfs supports forgetting devices that don't exist, we can add
> > a udev rule to take advantage of that. This avoids bad edge cases
> > with cached devices in multi-device filesystems without having to rescan
> > all the devices on every change.
> >
> > Signed-of-by: Boris Burkov <boris@bur.io>
> > ---
> > 64-btrfs-rm.rules | 7 +++++++
> > Makefile | 2 +-
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> > create mode 100644 64-btrfs-rm.rules
> >
> > diff --git a/64-btrfs-rm.rules b/64-btrfs-rm.rules
> > new file mode 100644
> > index 000000000..852155d28
> > --- /dev/null
> > +++ b/64-btrfs-rm.rules
> > @@ -0,0 +1,7 @@
>
> Please add a comment that explains when and why this udev rule should be
> used.
>
Definitely happy to add a comment.
This is certainly the discussion I was hoping to have, as well, but I
thiiink we just always want this? Basically if we don't have it,
multi-device users are in danger of accidentally making a stale device
cache between mounts. It's probably not that big of a risk in general,
but we did hit an easier to hit variant in v5.19 at Meta.
OTOH, there is also the problem that this is a no-op unless the kernel
has the patch I sent at the same time:
btrfs: support device name lookup in forget
I don't think there is any downside to running this command which will
simply fail on an older kernel.
If this becomes ubiquitous, then we can also remove the special case for
single device cache clearing from the btrfs unmount code.
> > +SUBSYSTEM!="block", GOTO="btrfs_rm_end"
> > +ACTION!="remove", GOTO="btrfs_rm_end"
> > +ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_rm_end"
> > +
> > +RUN+="/usr/local/bin/btrfs device scan -u $devnode"
>
> Is the full path mandatory or is 'btrfs' sufficient? I think systemd
> uses own tool of the same name.
Unfortunately, it did not work for me. I saw logs saying
/usr/lib/udev/rules.d/btrfs file not found or something like that in
dmesg.
I also considered the btrfs udev "builtin" but from experimenting and
checking out the code, it looks like that only does device ready, not
all device commands.
>
> Please use long option name so it's more obvious what it does.
next prev parent reply other threads:[~2024-02-29 20:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 18:36 [PATCH 0/2] btrfs-progs: forget removed devices Boris Burkov
2024-02-29 18:36 ` [PATCH 1/2] btrfs-progs: allow btrfs device scan -u on dead dev Boris Burkov
2024-02-29 18:36 ` [PATCH 2/2] btrfs-progs: add udev rule to forget removed device Boris Burkov
2024-02-29 19:53 ` David Sterba
2024-02-29 20:34 ` Boris Burkov [this message]
2024-03-01 2:31 ` [PATCH 0/2] btrfs-progs: forget removed devices Anand Jain
2024-03-01 11:54 ` David Sterba
2024-03-01 15:44 ` Boris Burkov
2024-03-04 18:07 ` David Sterba
2024-03-04 21:27 ` Boris Burkov
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=20240229203409.GA1754735@zen.localdomain \
--to=boris@bur.io \
--cc=dsterba@suse.cz \
--cc=kernel-team@fb.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