Util-Linux package development
 help / color / mirror / Atom feed
From: Xen <list@xenhideout.nl>
To: Util linux <util-linux@vger.kernel.org>
Cc: Karel Zak <kzak@redhat.com>
Subject: Re: PV on disk without partitions not recognised as LVM2_member
Date: Sat, 20 Aug 2016 16:13:52 +0200	[thread overview]
Message-ID: <3e1c8c5e88416d24f87bd411ca60488d@dds.nl> (raw)
In-Reply-To: <20160819111429.4rsuedff24inn4gu@ws.net.home>

Karel Zak schreef op 19-08-2016 13:14:

> This is very unusual setup, but according to feedback from LVM guys
> it's supported, so I will improve blkid to support it too.

Actually there are more issues. If you have any firmware RAID signature 
at the end of your disk, but you are not using it, blkid will also give 
that raid signature precendence over LVM2_member, but LVM depends on 
that blkid scan to know what to do; and will fail to scan (even though 
pvscan could handle it easily) when the required Udev rule doesn't 
match.

So when this part is fixed, anyone who has mistakenly perhaps created a 
raid array out of their firmware BIOS, will end up with the same 
situation because .... how are we going to let LVM2_member take 
precedence just because it uses blkid to decide when to call itself 
honey?

I mean I can see good reasons why a RAID signature would take 
precedence.

In this case it just disrupts the system LVM2 has set up, in which there 
is no redundancy and it depends on an external tool to do its scanning 
:-/.

If you replaced that entire udev rule file with just a single command 
(and a block device filter) it would just always work with no pain, but 
because they want to minimize the number of pvscan invocations (even if 
it is just 3 extra invocations that don't harm anyone at every boot) the 
system now fails to work. In its entirety. Because it depends on blkid 
to provide the right signature.

So basically they could simplify the system and do away with udev in 
that sense at the cost of a minimal amount of extra pvscan invocations 
that don't really bring any cost to the table. But would they do it?

You now have a problem that cannot be solved:

- blkid cannot be asked to give precedence to LMV2_member over raid 
signatures
- while lvm2 chooses to depend on blkid, it won't find all PVs. It 
limits its search, but you can't really blame blkid for that unless 
blkid started giving multiple results for every device. It would need to 
become a list, a set. You can't ask that of blkid just for that right. 
So now you have an issue that has no solution. Because they depend on 
blkid instead of their own internal code, which wasn't really all that 
necessary. I mean it is nice to be needed at times.

But the only solution that would really be painless is to just dump that 
lvm2 udev file and replace it with something extremely simple. :-/. ;-).

What can I say. It seems obvious.

I mean that doesn't take away from the current issue with blkid not 
recognising PV when Grub is present. But it does show the bigger problem 
in this... I think.

Anyway, regards, and sorry for the verbosity at times. Regards.


  parent reply	other threads:[~2016-08-20 14:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-18 20:39 PV on disk without partitions not recognised as LVM2_member Xen
2016-08-19  9:45 ` Xen
2016-08-19 11:14 ` Karel Zak
2016-08-19 15:10   ` Xen
2016-08-20 13:30   ` Xen
2016-08-20 14:13   ` Xen [this message]
2016-08-22  8:40     ` Karel Zak
2016-08-22 12:16       ` Xen
2016-08-30 10:24   ` Karel Zak

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=3e1c8c5e88416d24f87bd411ca60488d@dds.nl \
    --to=list@xenhideout.nl \
    --cc=kzak@redhat.com \
    --cc=util-linux@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