linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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"
> 


  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).