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.
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?
Is it necessary to tag all metadata with its source, so filters can be applied correctly?
Tagging metadata with its source could greatly assist debugging too.
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).
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
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.
(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.
(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).
(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.
(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!
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.
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.