From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Hannes Reinecke <hare@suse.de>,
device-mapper development <dm-devel@redhat.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>,
Kay Sievers <kay.sievers@vrfy.org>,
systemd Mailing List <systemd-devel@lists.freedesktop.org>,
Mike Snitzer <snitzer@redhat.com>
Subject: Re: multipath breaks with recent udev/systemd
Date: Mon, 15 Dec 2014 17:53:28 +0500 [thread overview]
Message-ID: <548ED9C8.4030200@gmail.com> (raw)
In-Reply-To: <548EAA80.30604@suse.de>
15.12.2014 14:31, Hannes Reinecke wrote:
> Hi all,
>
> in commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> (udev: serialize/synchronize block device event handling with file
> locks) udev started using flock() on the device node, supposedly to
> synchronize with an ominous 'block event handling'.
This is a duplicate of the issue that I have reported earlier:
https://www.redhat.com/archives/dm-devel/2014-October/msg00210.html
Therefore, I want to be CCed on replies.
>
> The code looks like this:
>
> if (d) {
> fd_lock = open(udev_device_get_devnode(d),
> O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
> if (fd_lock >= 0 && flock(fd_lock,
> LOCK_SH|LOCK_NB) < 0) {
> log_debug("Unable to flock(%s),
> skipping event handling: %m", udev_device_get_devnode(d));
> err = -EWOULDBLOCK;
> goto skip;
> }
> }
>
> However, multipath since several years is using a similar construct
> to lock all devices belonging to a multipath device table before
> creating a mulitpath dm-device:
>
> vector_foreach_slot (mpp->pg, pgp, i) {
> if (!pgp->paths)
> continue;
> vector_foreach_slot(pgp->paths, pp, j) {
> if (lock && flock(pp->fd, LOCK_SH | LOCK_NB) &&
> errno == EWOULDBLOCK)
> goto fail;
> else if (!lock)
> flock(pp->fd, LOCK_UN);
> }
> }
>
> So during bootup it's anyone's guess who's first, multipath or udev.
> And depending on the timing either multipath will fail to setup
> the device-mapper device or udev will simply ignore the device.
> Neither of those is a good, but the first is an absolute killer for
> modern systems which _rely_ on udev to configure devices.
>
> So how it this supposed to work?
> Why does udev ignore the entire event if it can't get the lock?
> Shouldn't it rather be retried?
> What is the supposed recovery here?
>
> Cheers,
>
> Hannes
>
--
Alexander E. Patrakov
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
next prev parent reply other threads:[~2014-12-15 12:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-15 9:31 multipath breaks with recent udev/systemd Hannes Reinecke
2014-12-15 12:53 ` Alexander E. Patrakov [this message]
2014-12-16 22:10 ` Benjamin Marzinski
2014-12-16 22:18 ` [dm-devel] " Benjamin Marzinski
2014-12-17 12:04 ` Hannes Reinecke
2014-12-18 20:18 ` Kay Sievers
2014-12-18 22:04 ` Benjamin Marzinski
2014-12-19 7:21 ` Hannes Reinecke
2014-12-19 15:16 ` Benjamin Marzinski
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=548ED9C8.4030200@gmail.com \
--to=patrakov@gmail.com \
--cc=bmarzins@redhat.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=snitzer@redhat.com \
--cc=systemd-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.