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...
Zdenek
_______________________________________________
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/
