Re: commit c527a0cbfc3 may have a bug

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 2020-02-14 21:40 David Teigland ha scritto:
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.

https://bugzilla.redhat.com/show_bug.cgi?id=1803266

Hi David, I think that part of the problem is the unclear/vague description of filters (eg: "plain" filter vs global_filter). In other words, maybe the real problem is a documentation one.

For example: am I right saying that global_filter were introduced as a "fail-safe" mechanism to protect udev & the likes by command-line-overwritten "plain" filter directive?

If so, I am not sure the comment in lvm.conf fully convey this message (and I can not find much on man pages, also). If not, and I am wrong about filter vs global_filter, then, well, this somewhat proves the point above :)

Thanks.

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


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux