[linux-lvm] commit c527a0cbfc3 may have a bug

Zdenek Kabelac zkabelac at redhat.com
Sat Feb 15 20:19:44 UTC 2020

Dne 15. 02. 20 v 20:15 Gionatan Danti napsal(a):
> Il 2020-02-15 13:40 Zdenek Kabelac ha scritto:
>> Dne 14. 02. 20 v 21:40 David Teigland napsal(a):
>>> On Fri, Feb 14, 2020 at 08:34:19PM +0100, Gionatan Danti wrote:
>>>> Hi David, being filters one of the most asked questions, can I ask why we
>>>> have so many different filters, leading to such complex interactions and
>>>> behaviors?
>>>> Don't get me wrong: I am sure you (the lvm team) have very good reasons to
>>>> do that, and I am surely missing something? But what, precisely? How should
>>>> we (end users) consider filters? Should we only use global_filter?
>>> You're right, filters are difficult to understand and use correctly. The
>>> complexity and confusion in the code is no better.  With the removal of
>>> lvmetad in 2.03 versions (e.g. RHEL8) there's no difference between filter
>>> and global_filter, so that's some small improvement.  But, I think filters
>>> should be replaced or overhauled with something easier to use and more
>>> useful at a technical level.
>>> I've created a bz about that and welcome thoughts about what a replacement
>>> should or should not be like.  With input the work is more likely to be
>>> prioritized.
>> One of the 'reason' for having 2 sets of filter was the presence of
>> universal 'scanning' tool (aka udev) - which is assessing & reading
>> devices in a system and its combination with various 'VM' environments
>> where actual device are passed to guest systems on your hosting
>> machine.
>> So there are many different combinations where different commands may
>> need to see different subset of devices - so i.e. your guest machine
>> should not have an impact on correctness of your 'hosting' machine no
>> matter what guess will write (i.e. duplicating signatures...)
> Sure. But why having a single, valid filter set is not sufficient? In other 
> words, why/when I can not simply using global_filter, ignoring "plain" filter?

The problem with simple filter - that was 'tried' to be resolved for lvmetad was:

udev should 'see' all devices in your system - so lvmetad should know about 
all devices in the system  (even with duplicates and all sort of 
inconsistencies and garbage) - the idea was 'nice', but the actual 
implementation itself was rising more troubles that it has been solving.

But ATM - we still have sort of 'pvscan' from udev
and  lvm command run by admin - which can run with different '--config'.

So the 'current' (ATM) difference is:

global_filter -  never scan such devices on a machine

filter  -  never scan device within a single command.

and the idea is - you can have 'different' sets of command operating on 
different subset of device on your machine  - which might be useful in the 
world of 'containers' & VMs & clusters...

So while 'global_filter' should mostly never change -  the change of filter is 
kind of ok during system's lifetime.

When there is no lvmetad anymore -  having 2 different 'filter' settings is 
now 'less' fancy and both cases could be somehow solved with just a single 
filter (as there is simply no cache and there is always some scan) -
but the correctness with VMs and other bigger systems could be better handled 
with 2 filter levels -  where basically 'admin' sets  'hard' borders with
global_filter - and tools can play with 'filter' with already preselected
subset of devices...

As has been said - it's not too much useful if there are just couple of disks 

>> It's worth to note lvm2 is solving way more issues then other similar
>> device technology (i.e. mdraid, btrfs....) where it's very simple to
>> cause big confusion and data corruptions (even unnoticed) once
>> duplicates appears in your system...
>> Zdenek
> I never duplicate devices with mdraid, but BTRFS is so fragile that taking a 
> simple LVM snapshot of a BTRFS component device can lead to data corruption.
> I really think the gold standard here is ZFS.

IMHO ZFS is 'somewhat' slow to play with...
and I've no idea how ZFS can resolve all correctness issues in kernel...


More information about the linux-lvm mailing list