[linux-lvm] commit c527a0cbfc3 may have a bug

Gionatan Danti g.danti at assyoma.it
Sat Feb 15 19:15:57 UTC 2020

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?

> While in many cases for many single home users with single set of
> devices this can be seen maybe as an 'overkill' solution - in the more
> generic world where there is unfortunately not yet any widely
> used/accepted solution solving the core problem: 'who is the owner of
> a device'  having several sets of filter was the only solution we were
> able to create.

True. I myself saw some setup where hosts had direct visibility of 
guest-created logical volumes. The obvious solution was to correctly set 
global_filter. However, I have the impression that a good share of 
complexity/issues/unexpected behaviors are due to LVM being able to be 
nested (PV inside LV inside VG inside PV inside ...)

> 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.

Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it [1]
email: g.danti at assyoma.it - info at assyoma.it
GPG public key ID: FF5F32A8

More information about the linux-lvm mailing list