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

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

[Alexander Lyakas]

[-- Attachment #1: Type: text/plain, Size: 2537 bytes --]

Hello Zdenek,
I am testing a following scenario:

I have 5 dm-linear devices, which I have setup manually using dmsetup.
Their table points at some local disks, like this:
/dev/mapper/alex0 => /dev/sda
/dev/mapper/alex1 => /dev/sdb

I create a VG on top of these 5 dm devices, using pvcreate and then
lvmlib APIs. The VG has no LVs at this point.
Later I teardown all the dm devices (using dmsetup remove).
Then I recreate the 5 dm devices, I give them the same names and setup
the same linear tables.

The difference is that I create them in different order.
So, for example, previously I had /dev/mapper/alex0 pointing at
/dev/sda, and it's real devnode was /dev/dm-0 (251:0), now
/dev/mapper/alex0 still points at /dev/sda, but its devnode is
/dev/dm-1 (251:1).
The names that I feed to LVM are always  /dev/mapper/alex0,
/dev/mapper/alex1 ...

In my application (at present) the lvm_t handle is not closed until
the application exits.

The issue that I see is in _cache.devices handling: it maps devt to
'struct device*' objects. So when searching for 251:1, a stale entry
for 251:1 is found (former /dev/mapper/alex1). So it contains an old
list of aliases in dev->aliases, and now a new name is added there, so
it contains now both /dev/mapper/alex0 and /dev/mapper/alex1 (and also
other names)...

In addition, this entry has dev->pvid of the /dev/mapper/alex1 PV.

Further I see a call to lvmcache_add with the following parameters:
pvid = correct pvid of /dev/mapper/alex0 (pointing at /dev/sda)
dev->pvid = the pvid of /dev/mapper/alex1

As a result, the _pvid_hash gets messed up...basically it ends up
having 4 PVs instead of 5. I am attaching a text file, which traces
the contents of the _pvid_hash during lvmcache_add call (I added some
prints there).

So it looks like having an open lib_t handle cannot survive such a
change in dev_t.

I have a couple of questions:
- Is my analysis (at least more or less) correct?
- Is this generally a bad idea to have dm-linear devices for PVs? (I
guarantee that dm-linear table is always setup correctly).
- Will using a fresh lib_t handle for each LVM operation solve this
issue? Because the command-line tools, when invoked, seem to work fine
(and they build a fresh cache each time). I will guarantee that nobody
else touches relevant dm devices during the LVM operation.
- I also see that LVM scans devices like /dev/disk/by-id... while in
lvm.conf I set the filter to accept only /dev/mapper/alex (all others
I set to reject). What am I missing?

Thanks for your help,
  Alex.

[-- Attachment #2: analysis_zdenek.txt --]
[-- Type: text/plain, Size: 2485 bytes --]

lvmcache_add
Oct 18 18:01:18 vc-0-0-7-01--nightly--118 prog: &&&&&&&&&& Before: pvid=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, dev=251:5, dev->pvid=Cx4gK1NwW3IUGU7Dj1Tw4TXH0G65fw2Q

_pvid_hash before:
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x722138: key=PYzixfmLTDdpJrCR67kVZTBC7USJY0wy, pvid=PYzixfmLTDdpJrCR67kVZTBC7USJY0wy, 251:9
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x70b2a8: key=Cx4gK1NwW3IUGU7Dj1Tw4TXH0G65fw2Q, pvid=Cx4gK1NwW3IUGU7Dj1Tw4TXH0G65fw2Q, 251:5
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x721d98: key=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, pvid=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, 251:3
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x70b9c8: key=QFx9B2pcEHEzgbGImcTPpXedROsx0t9z, pvid=QFx9B2pcEHEzgbGImcTPpXedROsx0t9z, 251:1
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x75aeb8: key=amf0lOCoaJyoXCkfsCaBkWDJhgircufZ, pvid=amf0lOCoaJyoXCkfsCaBkWDJhgircufZ, 251:7

'existing' pointer:
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x721d98: key=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, pvid=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, 251:3

Error message:
Oct 18 18:09:18 nightly--118 prog: Found duplicate PV 5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1: using /dev/mapper/vpart-52481 not /dev/disk/by-id/dm-name-vpart-52481

existing->dev = dev
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x721d98: key=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, dev->pvid=Cx4gK1NwW3IUGU7Dj1Tw4TXH0G65fw2Q, 251:5

_lvmcache_update_pvid:
remove entry with key Cx4gK1NwW3IUGU7Dj1Tw4TXH0G65fw2Q
_pvid_hash:
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x722138: key=PYzixfmLTDdpJrCR67kVZTBC7USJY0wy, pvid=PYzixfmLTDdpJrCR67kVZTBC7USJY0wy, 251:9
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x721d98: key=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, pvid=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, 251:3
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x70b9c8: key=QFx9B2pcEHEzgbGImcTPpXedROsx0t9z, pvid=QFx9B2pcEHEzgbGImcTPpXedROsx0t9z, 251:1
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x75aeb8: key=amf0lOCoaJyoXCkfsCaBkWDJhgircufZ, pvid=amf0lOCoaJyoXCkfsCaBkWDJhgircufZ, 251:7

'info' pointer gets dev->pvid updated:
Oct 18 18:01:19 nightly--118 prog: &&&&&&& lvmcache_info 0x721d98: key=5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1, dev->pvid="5x2JQxKi6GG3Mtw0ZrX2YPR9RCaYU0Z1", 251:5

trying to insert 'info', but another entry with the same key already exists...

from here we basically lost one PV in _pvid_hash

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

[Zdenek Kabelac]

2011/10/18 Alexander Lyakas <alex.bolshoy@gmail.com>:
> Hello Zdenek,
> I am testing a following scenario:
>
> I have 5 dm-linear devices, which I have setup manually using dmsetup.
> Their table points at some local disks, like this:
> /dev/mapper/alex0 => /dev/sda
> /dev/mapper/alex1 => /dev/sdb
>
> I create a VG on top of these 5 dm devices, using pvcreate and then
> lvmlib APIs. The VG has no LVs at this point.

Not really sure about lvmlib API capabilities - IMHO I'd not use it
for anything else then lvs-like operations ATM.  (since there are
quite a few rules to avoid deadlocks) If it's not a problem for you
app I'd suggest to use lvm2cmd library preferable in a separate forked
small process so there could be full control over memory and file
descriptors....

> Later I teardown all the dm devices (using dmsetup remove).
> Then I recreate the 5 dm devices, I give them the same names and setup
> the same linear tables.
>
> The difference is that I create them in different order.
> So, for example, previously I had /dev/mapper/alex0 pointing at
> /dev/sda, and it's real devnode was /dev/dm-0 (251:0), now
> /dev/mapper/alex0 still points at /dev/sda, but its devnode is
> /dev/dm-1 (251:1).
> The names that I feed to LVM are always �/dev/mapper/alex0,
> /dev/mapper/alex1 ...

dm-xxx devices are created dynamicaly - there is currently no way to
have a fixed dm device node and it would be quite ugly to provide such
feature.

So at dm level - you could use   /dev/mapper/devicename however at lvm
level the only supported way  is /dev/vg/lv
(even though they are visible through /dev/mapper  - only /dev/vg  are
meant to be 'public')

>
> The issue that I see is in _cache.devices handling: it maps devt to
> 'struct device*' objects. So when searching for 251:1, a stale entry
> for 251:1 is found (former /dev/mapper/alex1). So it contains an old
> list of aliases in dev->aliases, and now a new name is added there, so
> it contains now both /dev/mapper/alex0 and /dev/mapper/alex1 (and also
> other names)...
>
> In addition, this entry has dev->pvid of the /dev/mapper/alex1 PV.

Could be there is some bug in there - could you post a some simple
source file to expose this bug?

>
> Further I see a call to lvmcache_add with the following parameters:
> pvid = correct pvid of /dev/mapper/alex0 (pointing at /dev/sda)
> dev->pvid = the pvid of /dev/mapper/alex1
>
> As a result, the _pvid_hash gets messed up...basically it ends up
> having 4 PVs instead of 5. I am attaching a text file, which traces
> the contents of the _pvid_hash during lvmcache_add call (I added some
> prints there).
>
> So it looks like having an open lib_t handle cannot survive such a
> change in dev_t.

Maybe you could try to open bugzilla - where you would attach source file,
lvm.conf  and version you are trying to use.

>
> I have a couple of questions:
> - Is my analysis (at least more or less) correct?
> - Is this generally a bad idea to have dm-linear devices for PVs? (I
> guarantee that dm-linear table is always setup correctly).

It's perfecly normal usage - but it depends on your  lvm.conf filter settings
(i.e. if you will allow only   /dev/sdX devices,  then  /dev/mapper/
devices will be invisible)


> - Will using a fresh lib_t handle for each LVM operation solve this
> issue? Because the command-line tools, when invoked, seem to work fine
> (and they build a fresh cache each time). I will guarantee that nobody
> else touches relevant dm devices during the LVM operation.

Yes, there is locking, so as long as you are using only lvm tools,
there should be no collisions.

> - I also see that LVM scans devices like /dev/disk/by-id... while in
> lvm.conf I set the filter to accept only /dev/mapper/alex (all others
> I set to reject). What am I missing?

Recent versions of lvm should be getting list of block devices for
scanning from udev, and then more filters are applied.

Zdenek

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

[Matecki, Lukas]

Hallo List,

We are using LVM with SAN and multipathd. I try to setup mirroring with LVM. So I do pv create on a mpath device. vgcreate, add the pv to the vg, create a lv and setup a mirror with this:

lvconvert -m1 vg<name>/lv<name> /dev/mapper/mpath0 --mirrorlog core

My intention is to create a logical volume which can handle SAN Disk failure.

But in this shown setup i get a error (unavailable logical volume) when one of the san LUNS is missing.

Can this system work or did i need to setup a mdadm device before pvcreate ?

Hope you can help me because Redhat can't... them sitting two weeks on this error / miss configuration without any solution...

Greetings

Luke

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

[Alexander Lyakas]

Hi Zdenek,

It appears that I don't understand part of your comments, or perhaps
we have a disconnect.

> Not really sure about lvmlib API capabilities - IMHO I'd not use it
> for anything else then lvs-like operations ATM. �(since there are
> quite a few rules to avoid deadlocks) If it's not a problem for you
> app I'd suggest to use lvm2cmd library preferable in a separate forked
> small process so there could be full control over memory and file
> descriptors....
Do you suggest not to use lvmlib at all? And always use command-line
LVM tools from within a forked process? Currently I use
command-line/fork only for pvcreate/pvremove, since these APIs are not
available in lvmlib.

> dm-xxx devices are created dynamicaly - there is currently no way to
> have a fixed dm device node and it would be quite ugly to provide such
> feature.
I did not understand this comment. Do you mean the dm-xxx devices that
LVM creates for its LVs? I was talking about dm-linear devices that I
use for PVs.

>
> So at dm level - you could use � /dev/mapper/devicename however at lvm
> level the only supported way �is /dev/vg/lv
> (even though they are visible through /dev/mapper �- only /dev/vg �are
> meant to be 'public')
Again, do you mean the LV dm-xxx devices? I was talking about PV
devices, which are dm-linear in my case.

> Yes, there is locking, so as long as you are using only lvm tools,
> there should be no collisions.
What I meant here, is that each time a command-line tool is invoked,
it has a fresh instance of caches of its own. While in my application,
if I keep the lvm_t handle open, then the caches within lvm are not
cleaned up. This (plus the change in dev_t) causes the problem I am
seeing.

> Recent versions of lvm should be getting list of block devices for
> scanning from udev, and then more filters are applied.
Is there an option to restrict this list only to certain devices? In
my system there is no point of scanning all the devices.

All in all, I fixed my code to issue lvm_config_reload() before each
LVM operation. This cleans all the caches, so I am not seeing the
problem anymore.

Basically, I looked at the various caches code in the LVM, and they
seem quite dangerous to me, if not refreshed before each LVM
operation. Since most LVM usage (I presume) is done via command-line
tools, which create a new process (i.e., new caches) each time
invoked, not sure how big is the gain of caching. But I am probably
not seeing the whole picture.

Thanks,
  Alex.

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

[Zdenek Kabelac]

2011/10/24 Alexander Lyakas <alex.bolshoy@gmail.com>:
> Hi Zdenek,
>
> It appears that I don't understand part of your comments, or perhaps
> we have a disconnect.
>
>> Not really sure about lvmlib API capabilities - IMHO I'd not use it
>> for anything else then lvs-like operations ATM. �(since there are
>> quite a few rules to avoid deadlocks) If it's not a problem for you
>> app I'd suggest to use lvm2cmd library preferable in a separate forked
>> small process so there could be full control over memory and file
>> descriptors....
> Do you suggest not to use lvmlib at all? And always use command-line
> LVM tools from within a forked process? Currently I use
> command-line/fork only for pvcreate/pvremove, since these APIs are not
> available in lvmlib.

If you expect stable behavior - and the best memory efficiency and the
most supported features
 - then I'd go this way for now.



>
>> dm-xxx devices are created dynamicaly - there is currently no way to
>> have a fixed dm device node and it would be quite ugly to provide such
>> feature.
> I did not understand this comment. Do you mean the dm-xxx devices that
> LVM creates for its LVs? I was talking about dm-linear devices that I
> use for PVs.

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


>> So at dm level - you could use � /dev/mapper/devicename however at lvm
>> level the only supported way �is /dev/vg/lv
>> (even though they are visible through /dev/mapper �- only /dev/vg �are
>> meant to be 'public')
> Again, do you mean the LV dm-xxx devices? I was talking about PV
> devices, which are dm-linear in my case.

Always reference   /dev/vgname/lvname to stay safe.


>> Yes, there is locking, so as long as you are using only lvm tools,
>> there should be no collisions.
> What I meant here, is that each time a command-line tool is invoked,
> it has a fresh instance of caches of its own. While in my application,
> if I keep the lvm_t handle open, then the caches within lvm are not
> cleaned up. This (plus the change in dev_t) causes the problem I am
> seeing.

Internal caching knows it's changes devices and should properly flush them.

So if you get there some unexpected behavior - create a simple test case code,
and create regular bug.

(open handle, make few lvm2api operations causing problem)

>> Recent versions of lvm should be getting list of block devices for
>> scanning from udev, and then more filters are applied.
> Is there an option to restrict this list only to certain devices? In
> my system there is no point of scanning all the devices.

lvm.conf   - look for  setting 'filter='


> All in all, I fixed my code to issue lvm_config_reload() before each
> LVM operation. This cleans all the caches, so I am not seeing the
> problem anymore.
>
> Basically, I looked at the various caches code in the LVM, and they
> seem quite dangerous to me, if not refreshed before each LVM
> operation. Since most LVM usage (I presume) is done via command-line
> tools, which create a new process (i.e., new caches) each time
> invoked, not sure how big is the gain of caching. But I am probably
> not seeing the whole picture.

Yeah, you are not alone ;)
But in this case it looks like a bug you might be hitting - since this
case should work.

Zdenek

[linux-lvm] Remove a LUN from a LVM mirror cause logical volume not response

[Matecki, Lukas]

Second try this time with the right subject, sry Monday -.-

Hallo List,

We are using LVM with SAN and multipathd. I try to setup mirroring with LVM. So I do pv create on a mpath device. vgcreate, add the pv to the vg, create a lv and setup a mirror with this:

lvconvert -m1 vg<name>/lv<name> /dev/mapper/mpath0 --mirrorlog core

My intention is to create a logical volume which can handle SAN Disk failure.

But in this shown setup i get a error (unavailable logical volume) when one of the san LUNS is missing.

Can this system work or did i need to setup a mdadm device before pvcreate ?

Hope you can help me because Redhat can't... them sitting two weeks on this error / miss configuration without any solution...

Greetings

Luke

Re: [linux-lvm] Remove a LUN from a LVM mirror cause logical volume not response

[Hal Martin]

I don't have experience doing exactly what you're doing, but have you
checked that multipath is failing over correctly when your SAN is
missing a LUN?

Can you post the output of that command with '-vvvv' added?

-Hal

On Mon, Oct 24, 2011 at 8:48 AM, Matecki, Lukas <Lukas.Matecki@lvr.de> wrote:
> Second try this time with the right subject, sry Monday -.-
>
> Hallo List,
>
> We are using LVM with SAN and multipathd. I try to setup mirroring with LVM. So I do pv create on a mpath device. vgcreate, add the pv to the vg, create a lv and setup a mirror with this:
>
> lvconvert -m1 vg<name>/lv<name> /dev/mapper/mpath0 --mirrorlog core
>
> My intention is to create a logical volume which can handle SAN Disk failure.
>
> But in this shown setup i get a error (unavailable logical volume) when one of the san LUNS is missing.
>
> Can this system work or did i need to setup a mdadm device before pvcreate ?
>
> Hope you can help me because Redhat can't... them sitting two weeks on this error / miss configuration without any solution...
>
> Greetings
>
> Luke
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

Re: [linux-lvm] Remove a LUN from a LVM mirror cause logical volume not response

[Bryn M. Reeves]

On 10/24/2011 01:48 PM, Matecki, Lukas wrote:
> Second try this time with the right subject, sry Monday -.-
>
> Hallo List,
>
> We are using LVM with SAN and multipathd. I try to setup mirroring with LVM. So I do pv create on a mpath device. vgcreate, add the pv to the vg, create a lv and setup a mirror with this:

Bear in mind that if you are using multipath underneath a mirror then 
you will need to configure multipath to not queue I/O when all paths to 
a device fail (or to only do so for a limited number of retries).

Otherwise the system will queue all I/O and block accessing the side of
the mirror on the failed SAN.

> lvconvert -m1 vg<name>/lv<name>  /dev/mapper/mpath0 --mirrorlog core

Using core may not be the best idea here since it will mean that you 
have to resynchronize the mirror every time it is activated.

> My intention is to create a logical volume which can handle SAN Disk failure.
>
> But in this shown setup i get a error (unavailable logical volume) when one of the san LUNS is missing.

Can you paste the exact error you are getting? This doesn't sound like 
any LVM2 error message that I'm familiar with.

Regards,
Bryn.

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

[Stuart D. Gathman]

On Mon, 24 Oct 2011, Alexander Lyakas wrote:

>> dm-xxx devices are created dynamicaly - there is currently no way to
>> have a fixed dm device node and it would be quite ugly to provide such
>> feature.
> I did not understand this comment. Do you mean the dm-xxx devices that
> LVM creates for its LVs? I was talking about dm-linear devices that I
> use for PVs.

Why are you using dm-linear for PVs?

--
 	      Stuart D. Gathman <stuart@bmsi.com>
     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

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

[Alexander Lyakas]

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.

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

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

Thanks,
  Alex.

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

[Alexander Lyakas]

Hi Stuart,
with device mapper it's very easy to switch the underneath stack,
using dmsetup reload. (So now you would ask why would I want to do
it?)

Alex.


On Mon, Oct 24, 2011 at 7:52 PM, Stuart D. Gathman <stuart@bmsi.com> wrote:
> On Mon, 24 Oct 2011, Alexander Lyakas wrote:
>
>>> dm-xxx devices are created dynamicaly - there is currently no way to
>>> have a fixed dm device node and it would be quite ugly to provide such
>>> feature.
>>
>> I did not understand this comment. Do you mean the dm-xxx devices that
>> LVM creates for its LVs? I was talking about dm-linear devices that I
>> use for PVs.
>
> Why are you using dm-linear for PVs?
>
> --
> � � � � � � �Stuart D. Gathman <stuart@bmsi.com>
> � �Business Management Systems Inc. �Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flammis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
>

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

[Zdenek Kabelac]

2011/10/27 Alexander Lyakas <alex.bolshoy@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