Bug 989548 - Bogus "No device found for PV" messages if using lvmetad and devices/filter at the same time
Bogus "No device found for PV" messages if using lvmetad and devices/filter a...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
20
All Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Rockai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-29 10:07 EDT by Peter Rajnoha
Modified: 2015-06-29 08:08 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:08:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Rajnoha 2013-07-29 10:07:24 EDT
The pvscan --cache <device> does not honour the devices/filter setting - this is OK as lvmetad needs to keep global information about all devs (unless the devices/global_filter is set) and then each lvmetad client makes the filtering on its own.

However, there should not be the error message: "No device found for PV ..." if the PV was filtered on lvmetad client side as it's misleading, for example:

[0] raw/~ # systemctl status lvm2-lvmetad.service
lvm2-lvmetad.service - LVM2 metadata daemon
   Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmetad.service; disabled)
   Active: active (running) since Mon 2013-07-29 15:57:22 CEST; 3min 51s ago
     Docs: man:lvmetad(8)
  Process: 323 ExecStart=/usr/sbin/lvmetad (code=exited, status=0/SUCCESS)
 Main PID: 325 (lvmetad)
   CGroup: /system.slice/lvm2-lvmetad.service
           `-325 /usr/sbin/lvmetad
Jul 29 15:57:22 raw systemd[1]: Started LVM2 metadata daemon.

[0] raw/~ # pvs -o+uuid
  PV         VG         Fmt  Attr PSize  PFree PV UUID                               
  /dev/vda2  fedora_raw lvm2 a--  19.51g    0  WgtPbj-w1aa-2PDr-DcZq-8ijI-eVaZ-JwOqfy

[0] raw/~ # pvs --config 'devices{filter = [ "r%.*%" ] }'
  No device found for PV WgtPbj-w1aa-2PDr-DcZq-8ijI-eVaZ-JwOqfy.
Comment 1 Alasdair Kergon 2013-08-12 08:08:23 EDT
This is about more than just dealing with the error message.

Filtering means the device is not used at all.  No metadata read from the device is available to the code.

So how could the UUID be displayed in the error message if the only place with the UUID is the device that is not supposed to be being used?
Comment 2 Alasdair Kergon 2013-08-12 15:55:53 EDT
Is it necessary to tag all metadata with its source, so filters can be applied correctly?
Comment 3 Alasdair Kergon 2013-08-12 15:57:45 EDT
Tagging metadata with its source could greatly assist debugging too.
Comment 4 Petr Rockai 2013-08-22 13:37:37 EDT
Metadata does not always (or even usually) come from one particular place. The filters as they are implemented prevent the code from opening devices. The metadata comes from lvmetad, so all metadata is always available. But the code is prevented from reading from and writing to devices that are filtered out.

The situation is similar to what happens if you use file-based metadata.

I would say that the behaviour is OK and only the error message is a problem.

If you want to use filters to also hide VGs (as opposed to devices) from the command, there are two options: either add VG-based filtering (which would be inefficient without lvmetad, but would be sensible UI-wise) or remove VGs for which no PVs can be opened (this is somewhat inefficient with lvmetad and using device-based filters to hide VGs is not very user-friendly, especially with devices that do not have fixed names).
Comment 5 Fedora End Of Life 2013-09-16 10:53:24 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 6 Petr Rockai 2014-09-10 06:52:53 EDT
I have patched the code to print the following instead of an error when the device is not found due to a filter (as opposed to not existing):
  WARNING: Device @TESTDIR@/dev/mapper/@PREFIX@pv1 for PV 4WFU7h-49xe-1qWG-3dwe-cIcy-WAMQ-ZfzzV3 rejected by a filter.

I think this is adequate in most circumstances (it is mainly useful for VG or LV operations, where you try to use a filter and accidentally filter out a device that's part of a VG you are operating on). For pvs, you could argue that the warning should not be printed, although I am not convinced either way. If you only want data about particular pvs, you would be using pvs /dev/foo, not a filter.
Comment 7 Peter Rajnoha 2014-09-10 07:36:41 EDT
(In reply to Petr Rockai from comment #6)
> I have patched the code to print the following instead of an error when the
> device is not found due to a filter (as opposed to not existing):
>   WARNING: Device @TESTDIR@/dev/mapper/@PREFIX@pv1 for PV
> 4WFU7h-49xe-1qWG-3dwe-cIcy-WAMQ-ZfzzV3 rejected by a filter.
> 
> I think this is adequate in most circumstances (it is mainly useful for VG
> or LV operations, where you try to use a filter and accidentally filter out
> a device that's part of a VG you are operating on). For pvs, you could argue
> that the warning should not be printed, although I am not convinced either
> way. If you only want data about particular pvs, you would be using pvs
> /dev/foo, not a filter.

Well, yes, for pvs, I think it should work the same way as without lvmetad at least - we're not printing any warning messages in that case - it's just logged in the verbose log I think. As a user, I don't care about the warning since I've rejected the device myself with the devices/filter configuration.

This practically means that whenever I define devices/filter, I'll have the output spammed with those warnings.
Comment 8 Peter Rajnoha 2014-09-10 07:38:21 EDT
(In reply to Petr Rockai from comment #6)
> If you only want data about particular pvs, you would be using pvs
> /dev/foo, not a filter.

I want to list all PVs in the system (that, of course, comply with the filters used).
Comment 9 Petr Rockai 2014-09-10 10:29:02 EDT
(In reply to Peter Rajnoha from comment #7)
> This practically means that whenever I define devices/filter, I'll have the
> output spammed with those warnings.

No, because with lvmetad, we do not touch PVs outside of the current VG. If you filter out half of a VG, you will see warnings and/or errors, with lvmetad or without. If you filter out devices outside of the VG you are trying to work with, you won't see warnings because nothing references those filtered PVs.

The only cases where you will see warnings due to filters is when you try to work with all PVs or all VGs but use filters to hide some devices. I am not entirely sure which use-cases this serves better than listing PVs or VGs on the command line, using --config to set the filter on every command is rather unwieldy.

So if this seems important, we can suppress the warning/error if vgs or pvs is executed with a filter but without parameters.
Comment 10 Peter Rajnoha 2014-09-11 03:48:38 EDT
(In reply to Petr Rockai from comment #9)
> So if this seems important, we can suppress the warning/error if vgs or pvs
> is executed with a filter but without parameters.

Yes please, do so!
Comment 11 Fedora End Of Life 2015-05-29 05:13:36 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2015-06-29 08:08:07 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.