Re: commit c527a0cbfc3 may have a bug

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

 



Hello David,

I accept your points. the commit c527a0cbfc3 is correct.
I still not sure if the correct fix would have unintended consequences.
I think the most of people should only config device/filter in their machine.
After this commit, machine with duplicated devs should config 2 same copies filter rule.
one copy for device/filter, another for device/global_filter. It is wield.
The legacy code lived a period of time. Many of machine use it.

I quickly check the codes, before c527a0cbfc3, lvmetad_filter is
mainly used in _pvscan_cache() with in seldom condition. All other cases use device/filter.

So I suggest
1. Does lvm2 continue to keep the wrong filter(full_filter) usage?
   It can keep machine running as usual.
   or may add a new config item (e.g. pvscan_compat_filter = 0|1). let user to choose
filter behaviour

2. (a lot of work) backport mainline one filter code into stable-2.02 branch.

At last,
There is a little code tip for mainline branch:
To remove the in cfg_array(devices_global_filter_CFG in lib/config/config_settings.h
It generates useless config info.

Thanks.


On 2/15/20 4:40 AM, David Teigland wrote:
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.

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



_______________________________________________
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