[linux-lvm] Changing dev_t-devname mapping in lvmlib seems to be problematic

[Zdenek Kabelac]

2011/10/27 Alexander Lyakas <alex.bolshoy at gmail.com>:
> Hi Zdenek,
>
>> If you expect stable behavior - and the best memory efficiency and the
>> most supported features
>>  - then I'd go this way for now.
> It's quite frustrating, but I understand. Thanks.

As this new lvmapi is not yet fully finished - it's the solution which
gives you something that works now.
IMHO there is no big progress currently  in this api library - so I'd
not expect major upgrade in the near future.

>
>> /dev/dm-xxx   gets  its  'xxx' value in the order in which they appear
>> in the kernel processing.
>> Thus you should never ever depend on any fixed 'xxx' here - i.e. do
>> not reference /dev/dm-xxx
>> anywhere in you code - since it may change between reboots.
> Since my application is the one creating the dm-linear devices after
> boot, I am controlling their dm names. So I know exactly how to
> reference them.
>
>> lvm.conf   - look for  setting 'filter='
> I am using filter to match only a very small set of devices, something like:
> filter = [ "a|^/dev/mapper/alex-|", "r/.*/" ]
> So accept only something that looks like /dev/mapper/alex-...., reject
> everything else (right?).
>
> Still, when looking at a liblvm "_cache.devices" in gdb, I see a lot
> of devices there (~300). Perhaps the filter does not affect this
> particular cache.

The problem is the order of filter application - I've proposed to
switch the order, but it's not so simple as it might look.
In some cases the regular expression filter might be more expensive
then other type of filters so doing other checks before may give
better performance.  Anyway at the end  lvm should not read it's data
from filtered devices - while it might be possible to that during
filter processing some devices are read because filter with higher
priority may needed.

I'll try to probably propose a better version where the filter will
have it's priority and user may select what he prefers.
In my devel tree I keep the regex filter first - since it makes logs
considerably smaller ;)
(We may as well reevaluate the expensiveness of each filters to put
the in the best order - the fastest should be the first)

> I will try to put up a short code, which reproduces the problem....
> although to reproduce it, I need to create a couple of dm-linears,
> delete them, then re-create so that they receive different minor
> numbers. So the code might not be as short after all....

I'll take a look once it's ready.

Zdenek