ceph-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Rajnoha <prajnoha@redhat.com>
To: ceph-devel@vger.kernel.org
Cc: Loic Dachary <ldachary@redhat.com>,
	"Alasdair G. Kergon" <agk@redhat.com>,
	Zdenek Kabelac <zkabelac@redhat.com>
Subject: 60-ceph-partuuid-workaround.rules
Date: Mon, 18 Apr 2016 12:01:23 +0200	[thread overview]
Message-ID: <5714B073.6070809@redhat.com> (raw)

Hi!

I'm resending original mail to this list after initial
discussion with Loic Dachary so others can chime in. Loic
says these rules were there to workaround certain problems
on Centos 6 only and that it can be discarded now.

Please, read original mail below:

===

We've just noticed 60-ceph-partuuid-workaround.rules.

You added a patch some time ago which made these rules
to be applied for DM devices too:


https://github.com/ceph/ceph/commit/42ad86e14e352f2a3a33e774224f1789f268da83

The problem we've spotted and hit recently is that
these rules call blkid which opens all DM devices now
on uevents. However, not all DM devices are suitable
for scanning as they may not be prepared fully yet.
We use various flags in DM (and its subsystems like LVM)
to avoid these scans and for all the rules we don't manage,
there's DM_UDEV_DISABLE_OTHER_RULES_FLAG that needs to
be checked in these "foreign" rules before opening such
DM device (which includes running blkid).

Otherwise, we may end up with errors where some DM subsystem
needs to close the device or do some initialization on this
device before making it public by dropping the
DM_UDEV_DISABLE_OTHER_RULES_FLAG. So we need to make sure
these things are in sync - the scan can't be run on all DM
devices, it's controlled via DM_UDEV_*_FLAG variables.

Now, when it comes to the 60-ceph-partuuid-workaround.rules,
why do we need that at all? I mean, the 60-persistent-storage.rules
do not whitelist DM devices, so these rules are skipped anyway
and it was that way since beginning, I think. Now, I see this
comment in the 60-ceph-partuuid-workaround.rules:

# this is a kludge installed by ceph to fix the /dev/disk/by-partuuid
# symlinks on systems with old udev (< 180).  it's a stripped down
# version of a newer 60-persistent-storage.rules file that hopefully
# captures the same set of conditions for setting up those symlinks.

So I need to get to the bottom of the problem which was
resolved here. Feel free to point me to someone else if you're
not the right person, but I need to understand what's behind
these extra workaround rules so I can help to make it work
correctly with DM devices.

Thanks.

-- 
Peter

             reply	other threads:[~2016-04-18 10:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-18 10:01 Peter Rajnoha [this message]
2016-04-18 12:25 ` 60-ceph-partuuid-workaround.rules Sage Weil
2016-04-18 14:00   ` 60-ceph-partuuid-workaround.rules Owen Synge

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=5714B073.6070809@redhat.com \
    --to=prajnoha@redhat.com \
    --cc=agk@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=ldachary@redhat.com \
    --cc=zkabelac@redhat.com \
    /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).