From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Jeff Mahoney <jeffm@suse.com>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] btrfs-progs: udev: add rules for dm devices
Date: Sun, 8 May 2016 08:00:07 +0300 [thread overview]
Message-ID: <572EC7D7.8040608@gmail.com> (raw)
In-Reply-To: <6ddc2c5c-42df-e7ca-daff-8848cbc3d9e9@suse.com>
06.05.2016 22:27, Jeff Mahoney пишет:
> Systemd's btrfs rule runs btrfs dev ready on each device
> as it's discovered. The btrfs command is executed as a builtin
> command via an IMPORT{builtin} rule, which means it gets
> executed at rule evaluation time, not rule execution time. That
> means that the device mapper links haven't been setup yet and the only
> nodes that can be depended upon are /dev/dm-#. That we see
> /dev/mapper/name names in /proc/mounts is only because we replace the
> device name we have cached with the one passed in via mount. If
> we have a multi-device file system and the primary device is removed,
> the remaining devices will show /dev/dm-#. In addition, if the
And I still do not understand why it is bad while /dev/sd#n is good.
> udev rule is executed again by someone generating a change event (e.g.
> partprobe), the names are also replaced by the /dev/dm-# names.
>
> This patch adds a new rule that adds a run rule that calls btrfs dev
> ready again using the device mapper links once they're created.
> ---
> 64-btrfs-dm.rules | 10 ++++++++++
> Makefile.in | 7 +++++++
> configure.ac | 2 ++
> 3 files changed, 19 insertions(+)
> create mode 100644 64-btrfs-dm.rules
>
> diff --git a/64-btrfs-dm.rules b/64-btrfs-dm.rules
> new file mode 100644
> index 0000000..bbe1c35
> --- /dev/null
> +++ b/64-btrfs-dm.rules
> @@ -0,0 +1,10 @@
> +SUBSYSTEM!="block", GOTO="btrfs_end"
> +KERNEL!="dm-[0-9]*", GOTO="btrfs_end"
> +ACTION!="add|change", GOTO="btrfs_end"
> +ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
> +
> +# Once the device mapper symlink is created, tell btrfs about it
> +# so we get the friendly name in /proc/mounts (and tools that read it)
> +ENV{DM_NAME}=="?*", TEST=="/dev/mapper/$env{DM_NAME}", RUN{builtin}+="btrfs ready /dev/mapper/$env{DM_NAME}"
> +
That won't work for the very first event (presumably "add"). /dev/mapper
link is created only after all rules have been processed, so it will
always evaluate to false.
> +LABEL="btrfs_end"
> diff --git a/Makefile.in b/Makefile.in
> index 19697ff..d555f6a 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -83,11 +83,15 @@ libbtrfs_headers = send-stream.h send-utils.h send.h rbtree.h btrfs-list.h \
> extent_io.h ioctl.h ctree.h btrfsck.h version.h
> TESTS = fsck-tests.sh convert-tests.sh
>
> +udev_rules = 64-btrfs-dm.rules
> +
> prefix ?= @prefix@
> exec_prefix = @exec_prefix@
> bindir = @bindir@
> libdir ?= @libdir@
> incdir = @includedir@/btrfs
> +udevdir = @UDEVDIR@
> +udevruledir = ${udevdir}/rules.d
>
> ifeq ("$(origin V)", "command line")
> BUILD_VERBOSE = $(V)
> @@ -377,6 +381,9 @@ install: $(libs) $(progs_install) $(INSTALLDIRS)
> cp -a $(lib_links) $(DESTDIR)$(libdir)
> $(INSTALL) -m755 -d $(DESTDIR)$(incdir)
> $(INSTALL) -m644 $(headers) $(DESTDIR)$(incdir)
> +ifneq ($(udevdir), "")
> + $(INSTALL) -m644 $(udev_rules) $(DESTDIR)$(udevruledir)
> +endif
>
> install-static: $(progs_static) $(INSTALLDIRS)
> for p in $(progs_static) ; do \
> diff --git a/configure.ac b/configure.ac
> index fc343ea..4af7474 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -124,6 +124,8 @@ PKG_STATIC(UUID_LIBS_STATIC, [uuid])
> PKG_CHECK_MODULES(ZLIB, [zlib])
> PKG_STATIC(ZLIB_LIBS_STATIC, [zlib])
>
> +PKG_CHECK_VAR([UDEVDIR], [udev], [udevdir])
> +
> dnl lzo library does not provide pkg-config, let use classic way
> AC_CHECK_LIB([lzo2], [lzo_version], [
> LZO2_LIBS="-llzo2"
>
next prev parent reply other threads:[~2016-05-08 5:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-06 19:27 [PATCH] btrfs-progs: udev: add rules for dm devices Jeff Mahoney
2016-05-06 19:30 ` Jeff Mahoney
2016-05-08 5:00 ` Andrei Borzenkov [this message]
2016-05-09 1:33 ` Jeff Mahoney
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=572EC7D7.8040608@gmail.com \
--to=arvidjaar@gmail.com \
--cc=jeffm@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).