dmevent plugin

dmevent plugin

[M. Mohan Kumar]

Hello,

As per my understanding lvm2 does not support other applications to
register with dmevent daemon to handle events generated in interested
devices. Function monitor_dev_for_events() in lib/activate/activate.c
registers with the default events library (if its available).

When a dm-thinpool is created from SAN[1] and typically multiple hosts have
visibility to the same dm-thinpool. In this case there are chances that
more than one dm-eventd thin plugin will be registered to monitor
it. When dm-thinpool reaches low water mark threshold, these plugins try
to resize the thin-pool causing simultaneous block allocate requests and
dm-thin-pool module may not be capable to handle this situation.

There could be specific applications using this dm-thinpool in a SAN
environment and wanting to handle the dm-thinpool specific events by
themselves.

By using GlusterFS and BD xlator[2] we are planning to use dm-thinpool
to provide thin provisioned storage for hosting the VM images. This pool
could come from a SAN box but there will be a 1:1 mapping between
Glusterfs server and dm-thinpool. It provides controlled clustered
access to dm-thinpool when various Glusterfs clients access the same
dm-thinpool through single GlusterFS server. The idea is to extend the
dm-thinpool(when low water mark threshold reached) from respective
GlusterFS server so that there is only one entity controlling that
dm-thinpool in a clustered environment.

Is there any way to avoid this default registration? So that only
specific applicationcode can register itself with interested dm-thinpool
and take the necessary action when low watermark threshold is reached?

[1] Basic SAN without supporting thin provisioning
[2] http://review.gluster.com/#/c/4714/

dmevent plugin

[Zdenek Kabelac]

Dne 23.4.2013 20:30, M. Mohan Kumar napsal(a):
> Hello,
>
> As per my understanding lvm2 does not support other applications to
> register with dmevent daemon to handle events generated in interested

there was at least one non-lvm plugin from dmraid project.

dmeventd test is based on 'dmsetup status' - and the plugin is executing
lvm code only in case something triggers this action (i.e. fill over 
threshold) - but since lvm library is not threadsafe - only one plugin
could execute lvm code within mutex.


> devices. Function monitor_dev_for_events() in lib/activate/activate.c
> registers with the default events library (if its available).
>
> When a dm-thinpool is created from SAN[1] and typically multiple hosts have
> visibility to the same dm-thinpool. In this case there are chances that
> more than one dm-eventd thin plugin will be registered to monitor
> it. When dm-thinpool reaches low water mark threshold, these plugins try
> to resize the thin-pool causing simultaneous block allocate requests and
> dm-thin-pool module may not be capable to handle this situation.

dmeventd plugin for lvm thin pool is essentially calling command:

'lvextend --usepolicies'

when dmsetup status is report values above threashold.


> There could be specific applications using this dm-thinpool in a SAN
> environment and wanting to handle the dm-thinpool specific events by
> themselves.

Code from thin plugin might be easily duplicated and modified.

But since you are repeatedly mentioning  dm-thinpool - it seems like
you do not plan to lvm2 thin support here and you want to create
thin pool natively via dmsetup commands ?

> By using GlusterFS and BD xlator[2] we are planning to use dm-thinpool
> to provide thin provisioned storage for hosting the VM images. This pool
> could come from a SAN box but there will be a 1:1 mapping between
> Glusterfs server and dm-thinpool. It provides controlled clustered
> access to dm-thinpool when various Glusterfs clients access the same
> dm-thinpool through single GlusterFS server. The idea is to extend the
> dm-thinpool(when low water mark threshold reached) from respective
> GlusterFS server so that there is only one entity controlling that
> dm-thinpool in a clustered environment.

There is work-in-progress for clustered usage of thin pools.

> Is there any way to avoid this default registration? So that only

All LVs have monitoring feature so you could always disable monitoring
for particular LV - is that what you mean ?

> specific applicationcode can register itself with interested dm-thinpool
> and take the necessary action when low watermark threshold is reached?
>
> [1] Basic SAN without supporting thin provisioning
> [2] http://review.gluster.com/#/c/4714/
>
> --
> lvm-devel mailing list
> lvm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/lvm-devel
>

Zdenek

dmevent plugin

[M. Mohan Kumar]

Zdenek Kabelac <zkabelac@redhat.com> writes:

> Dne 23.4.2013 20:30, M. Mohan Kumar napsal(a):
>> Hello,
>>
Zdenek, thanks for the response.

>> As per my understanding lvm2 does not support other applications to
>> register with dmevent daemon to handle events generated in interested
>
> there was at least one non-lvm plugin from dmraid project.
>
> dmeventd test is based on 'dmsetup status' - and the plugin is executing
> lvm code only in case something triggers this action (i.e. fill over 
> threshold) - but since lvm library is not threadsafe - only one plugin
> could execute lvm code within mutex.
>
Yes, the plugins execute interested commands/actions only when a
specific event is generated, in thin pool case when it reaches the
threshold.
>
>> devices. Function monitor_dev_for_events() in lib/activate/activate.c
>> registers with the default events library (if its available).
>>
>> When a dm-thinpool is created from SAN[1] and typically multiple hosts have
>> visibility to the same dm-thinpool. In this case there are chances that
>> more than one dm-eventd thin plugin will be registered to monitor
>> it. When dm-thinpool reaches low water mark threshold, these plugins try
>> to resize the thin-pool causing simultaneous block allocate requests and
>> dm-thin-pool module may not be capable to handle this situation.
>
> dmeventd plugin for lvm thin pool is essentially calling command:
>
> 'lvextend --usepolicies'
>
> when dmsetup status is report values above threashold.
>
When I last checked 'lvextend' did not have --usepolicy option
enabled. Only lvconvert has this option, so even with thin plugin the
pool is not resized when it reached threshold. I have to patch thin
plugin to run lvresize command to increase the pool size and it worked.
>
>> There could be specific applications using this dm-thinpool in a SAN
>> environment and wanting to handle the dm-thinpool specific events by
>> themselves.
>
> Code from thin plugin might be easily duplicated and modified.
>
> But since you are repeatedly mentioning  dm-thinpool - it seems like
> you do not plan to lvm2 thin support here and you want to create
> thin pool natively via dmsetup commands ?
>
No, lvcreate will be used to create a thin pool.

>> By using GlusterFS and BD xlator[2] we are planning to use dm-thinpool
>> to provide thin provisioned storage for hosting the VM images. This pool
>> could come from a SAN box but there will be a 1:1 mapping between
>> Glusterfs server and dm-thinpool. It provides controlled clustered
>> access to dm-thinpool when various Glusterfs clients access the same
>> dm-thinpool through single GlusterFS server. The idea is to extend the
>> dm-thinpool(when low water mark threshold reached) from respective
>> GlusterFS server so that there is only one entity controlling that
>> dm-thinpool in a clustered environment.
>
> There is work-in-progress for clustered usage of thin pools.
>
Could you give some pointers to this work, like whats the current
status, target date et?

>> Is there any way to avoid this default registration? So that only
>
> All LVs have monitoring feature so you could always disable monitoring
> for particular LV - is that what you mean ?
>
Yeah, as a prerequisite we can ask users to disable monitoring
interested thin pool. But user has to do that in all nodes that are
connected to SAN, so I expected unless explicitly asked this default
registration should not happen.

>> specific applicationcode can register itself with interested dm-thinpool
>> and take the necessary action when low watermark threshold is reached?
>>
>> [1] Basic SAN without supporting thin provisioning
>> [2] http://review.gluster.com/#/c/4714/
>>
>> --
>> lvm-devel mailing list
>> lvm-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/lvm-devel
>>
>
> Zdenek

dmevent plugin

[Zdenek Kabelac]

Dne 24.4.2013 04:28, M. Mohan Kumar napsal(a):
> Zdenek Kabelac <zkabelac@redhat.com> writes:
>
>> Dne 23.4.2013 20:30, M. Mohan Kumar napsal(a):
>>> Hello,
>>>
> Zdenek, thanks for the response.
>
>>> As per my understanding lvm2 does not support other applications to
>>> register with dmevent daemon to handle events generated in interested
>>
>> there was at least one non-lvm plugin from dmraid project.
>>
>> dmeventd test is based on 'dmsetup status' - and the plugin is executing
>> lvm code only in case something triggers this action (i.e. fill over
>> threshold) - but since lvm library is not threadsafe - only one plugin
>> could execute lvm code within mutex.
>>
> Yes, the plugins execute interested commands/actions only when a
> specific event is generated, in thin pool case when it reaches the
> threshold.


So if you need to execute different code - you may just duplicate the code,
and replace the executable action with different code.

Currently the executed code in the plugin is not configurable.

On the other hand - you may write your own watching daemon - just
by polling and reading dmsetup status info even in a shell script.

Dmeventd is doing more things - but the main part is to be usable
on /root volumes - but since this is not your case, you may
write easily your own code to watching for pool limits.

>>> devices. Function monitor_dev_for_events() in lib/activate/activate.c
>>> registers with the default events library (if its available).
>>>
>>> When a dm-thinpool is created from SAN[1] and typically multiple hosts have
>>> visibility to the same dm-thinpool. In this case there are chances that
>>> more than one dm-eventd thin plugin will be registered to monitor
>>> it. When dm-thinpool reaches low water mark threshold, these plugins try
>>> to resize the thin-pool causing simultaneous block allocate requests and
>>> dm-thin-pool module may not be capable to handle this situation.
>>
>> dmeventd plugin for lvm thin pool is essentially calling command:
>>
>> 'lvextend --usepolicies'
>>
>> when dmsetup status is report values above threashold.
>>
> When I last checked 'lvextend' did not have --usepolicy option
> enabled. Only lvconvert has this option, so even with thin plugin the
> pool is not resized when it reached threshold. I have to patch thin
> plugin to run lvresize command to increase the pool size and it worked.

yep -  missing in man page, but it's there for quite long time.

>
>>> By using GlusterFS and BD xlator[2] we are planning to use dm-thinpool
>>> to provide thin provisioned storage for hosting the VM images. This pool
>>> could come from a SAN box but there will be a 1:1 mapping between
>>> Glusterfs server and dm-thinpool. It provides controlled clustered
>>> access to dm-thinpool when various Glusterfs clients access the same
>>> dm-thinpool through single GlusterFS server. The idea is to extend the
>>> dm-thinpool(when low water mark threshold reached) from respective
>>> GlusterFS server so that there is only one entity controlling that
>>> dm-thinpool in a clustered environment.
>>
>> There is work-in-progress for clustered usage of thin pools.
>>
> Could you give some pointers to this work, like whats the current
> status, target date et?

I'd estimate half year for some initial release. But currently there are only
some basic ideas for implementation of the proof-of-concept.
But it's hard to say whether it would be usable for anything mentioned here.


>> All LVs have monitoring feature so you could always disable monitoring
>> for particular LV - is that what you mean ?
>>
> Yeah, as a prerequisite we can ask users to disable monitoring
> interested thin pool. But user has to do that in all nodes that are
> connected to SAN, so I expected unless explicitly asked this default
> registration should not happen.

You can easily disable monitoring on all nodes in lvm.conf

Zdenek