linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Peter Rajnoha <prajnoha@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>
Cc: marius.vollmer@redhat.com
Subject: Re: [linux-lvm] Identifying useable block devices
Date: Mon, 20 Jan 2014 12:49:40 +0100	[thread overview]
Message-ID: <52DD0D54.6060704@redhat.com> (raw)
In-Reply-To: <87y52fdiyp.fsf@red.mvo.lan>

On 01/17/2014 11:02 AM, Marius Vollmer wrote:
> [ I am not subscribed, so please keep me in CC.  I'll just reply to
>   myself, sorry for breaking the threading.
> ]
> 
> Peter Rajnoha wrote:
> 
>> For now, these flags are only documented directly in libdevmapper.h
>> (as they were only meant to direct udev rules and these situations
>> were all audited directly by communicating with other teams).  I could
>> probably add a few lines to the man page directly though as others
>> could use this even when reading udev database...
> 
> That would be great!
> 
>> However, for your purpose, I'd better use
>> DM_UDEV_DISABLE_OTHER_RULES_FLAG which just tells that everything else
>> other than DM/LVM related should skip this device.
> 
> Hmm, DM_UDEV_DISABLE_OTHER_RULES_FLAG is (now) set for thin volumes, as
> far as I can tell.  This is what lead me down this rabbit hole in the
> first place: UDisks2 _does_ ignore events for nodes with
> DM_UDEV_DISABLE_OTHER_RULES_FLAG set, and since Fedora 20, this causes
> it to ignore thin volumes.
> 
> The use of DM_UDEV_DISABLE_OTHER_RULES_FLAG or any other such flag in
> UDisks2 looked like a ugly hack to me, so I started looking for
> alternatives.
> 
> The best option seemed to be to ignore any DISABLE flag in UDisks, and
> to set UDISKS_IGNORE for LVM2 block devices that do not have the
> /dev/VG/LV symlink.
> 
> Now you say that DM_UDEV_DISABLE_OTHER_RULES_FLAG is actually the Right
> Way, but it seems to be buggy re thin volumes.  Correct?
>

Thing here is that when LVs are created then at first they have this flag
set until proper initialization is finished - meaning zeroing of any existing
signatures found on the volume before this LV can be used cleanly (otherwise,
it could happen that some scanning done outside LVM could find stale metadata
on just created LV, like FS labels, MD signatures.. whatever that might pose
a confusion about what is layed on top of the LV). Only after the signature
wiping is done, the flag is dropped and so others are free to use it as the
LV is clean now.

However, you're right that in case of thin LVs, this is set incorrectly.
The DM_UDEV_DISABLE_OTHER_RULES flag should not be there. I've fixed that:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=91b26b63b408b7d7b4f79f0754d190783874e4cc

Thanks for spotting this!
-- 
Peter

  parent reply	other threads:[~2014-01-20 11:49 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15  8:19 [linux-lvm] Identifying useable block devices Marius Vollmer
2014-01-15 15:49 ` Alasdair G Kergon
2014-01-15 16:17 ` Oliver Rath
2014-01-15 20:24   ` Anatoly Pugachev
2014-01-16  1:32     ` Paul B. Henson
2014-01-16  5:42       ` Peter Rajnoha
2014-01-16 21:03         ` Paul B. Henson
2014-01-17  7:54           ` Peter Rajnoha
2014-01-17  9:29             ` Karel Zak
2014-01-17  9:53               ` Peter Rajnoha
2014-01-16  6:04 ` Peter Rajnoha
2014-01-17 10:02 ` Marius Vollmer
2014-01-17 13:35   ` Marius Vollmer
2014-01-20 11:52     ` Peter Rajnoha
2014-01-20 11:49   ` Peter Rajnoha [this message]
2014-01-20 12:02     ` Peter Rajnoha
2014-01-22  9:23       ` Marius Vollmer
2014-01-23 11:42         ` Peter Rajnoha
2014-01-23 12:35           ` Marius Vollmer
2014-01-24 13:24             ` Peter Rajnoha
2014-01-24 13:29               ` Peter Rajnoha
2014-01-24 14:39                 ` Marius Vollmer
2014-01-24 15:02                   ` Peter Rajnoha
2014-01-27  7:37                     ` Marius Vollmer
2014-01-24 14:50               ` Marius Vollmer
2014-01-24 15:08                 ` Peter Rajnoha
2014-01-24 15:17                 ` Zdenek Kabelac
2014-01-24 15:20                   ` Peter Rajnoha
2014-01-22  9:02     ` Marius Vollmer

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=52DD0D54.6060704@redhat.com \
    --to=prajnoha@redhat.com \
    --cc=linux-lvm@redhat.com \
    --cc=marius.vollmer@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).