Question about dmevents

Question about dmevents

[Wood, Brian J]

Hello everyone, I was wondering if someone could point me to a utility
that I could look at that uses the dmeventd event registration. I asked
Heinz M. if there were an LVM utilities that I could see sample code for
and it sounded like there weren't any implementations currently in LVM
(he did mention "mirrored.c" but that seems incomplete, unless I'm
missing something). I'm wondering if someone on this list has made some
sort of test utility that I could see the source code for (maybe a small
application and a "hello world" type DSO that I could learn from :) ). 

Thank you, 

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

Re: Question about dmevents

[Jonathan Brassow]

LVM mirroring is indeed one of the targets that makes use of this  
facility.

The device-mapper code base is the place to find the daemon (device- 
mapper/dmeventd).  This daemon resides in userspace waiting for  
events on devices that are being monitored (aka registered).  When an  
event is received from the kernel, it is passed to a registered  
shared library.  LVM2/dmeventd/mirror contains the dynamic shared  
object that handles mirror events.  (The important functions being  
'register', 'unregister', and 'process_event').

  brassow

On Jul 16, 2007, at 10:08 AM, Wood, Brian J wrote:

> Hello everyone, I was wondering if someone could point me to a utility
> that I could look at that uses the dmeventd event registration. I  
> asked
> Heinz M. if there were an LVM utilities that I could see sample  
> code for
> and it sounded like there weren't any implementations currently in LVM
> (he did mention "mirrored.c" but that seems incomplete, unless I'm
> missing something). I'm wondering if someone on this list has made  
> some
> sort of test utility that I could see the source code for (maybe a  
> small
> application and a "hello world" type DSO that I could learn from :) ).
>
> Thank you,
>
> Brian Wood
> Intel Corporation
> Digital Enterprise Group
> Manageability & Platform Software Division
> brian.j.wood@intel.com
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Question about dmevents

[Wood, Brian J]

Hello everyone, I have a question about something in the
"libdevmapper-event.c" code. I'm building a test application that I can
use to setup events I would like to register with dmeventd. As suggested
by Jonathan Brassow I've used the framework from lib/mirror/mirrored.c
in LVM2 as a template to creating my setup code in the test application.
Right now I'm hard coding in the name of the dso and the name of the
device I would like to register as a watch point. Here is how I get
things going: 

Create a structure "dm_event_handler"
Set char *dso to a stub dso (created for testing).
Set char *name to "/dev/mapper/XXXXX_Volume0p1" (one of my dm device
names) 
Call "dm_event_handler_create()"
Call "dm_event_handler_set_dso()"
Call "dm_event_handler_set_dev_name()"

After setting all this up I call "dm_event_register_handler()" passing
in the "dm_event_handler" structure. Inside this call the first thing is
a call to "_get_device_info()" that sets up my "dm_task" structure.
Inside this function I noticed the "dm_task_create()" function sets up
the dm_task structure, but leaves uuid as null. We then test uuid (since
its null it jumps past the first "if" statement heading into
dm_task_set_name()). In here it cuts off the "/dev/mapper/" and sets
dev_name to XXXXX and returns as it should.

After this long setup here's the problem I'm having. I run through the
remaining function calls in _get_device_info() and my uuid for the
dm_task is still null. The last call before sending this message off to
dmeventd using the "_do_event()" is a call to dm_task_get_uuid() that is
passed my dm_task struct. This should return a uuid string, but returns
null since my dm_task is never getting a uuid set. Without this I get a
failure on the dmeventd side stating I passed a null pointer into
dm_strdup via the function _alloc_thread_status (where it checks the
uuid field). 

Just as a test, in my gdb session I set the uuid to some text string,
"blah" for example, and I'm able to register my event and get a
"SUCCESS" message back in the FIFO. 

 
My one clue is that I noticed back in _get_device_info() a line that
says
 	/* FIXME Add name or uuid or devno to messages */
Does this mean that there needs to be code added to setup the dm_task
uuid? Or is there another call in libdevmapper.h that I'm missing that I
can use to set this up?

Thank you for any help you might be able to offer; I'm hoping I just
missed calling a libdevmapper* initialization function :)


Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

Re: Question about dmevents

[Alasdair G Kergon]

On Fri, Jul 20, 2007 at 09:02:18AM -0700, Wood, Brian J wrote:
>  	/* FIXME Add name or uuid or devno to messages */

'messages' just refers to the log messages - they don't provide sufficient context

Alasdair
-- 
agk@redhat.com

Re: Question about dmevents

[Alasdair G Kergon]

Obvious question - but first check your device actually has a uuid.
(Does 'dmsetup info' report it?)

Kernel-side, uuids are optional, but userspace applications are likely
to find it difficult to function reliably without them.

Alasdair
-- 
agk@redhat.com

RE: Question about dmevents

[Wood, Brian J]

Hi Alasdair, I just checked using "dmsetup info" and my mirrored logical
volume I created yesterday shows a UUID, but the raid1 my system runs on
doesn't? Just curious, should this UUID have been created during system
OS installation by device-mapper?

Thank you,     

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Alasdair G Kergon
>Sent: Friday, July 20, 2007 9:22 AM
>To: device-mapper development
>Subject: Re: [dm-devel] Question about dmevents
>
>Obvious question - but first check your device actually has a uuid.
>(Does 'dmsetup info' report it?)
>
>Kernel-side, uuids are optional, but userspace applications are likely
>to find it difficult to function reliably without them.
>
>Alasdair
>--
>agk@redhat.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

RE: Question about dmevents

[Wood, Brian J]

Hi Alasdair, I also read in the definition of DM_DEV_CREATE that the
uuid is optional. Since that is the case shouldn't the failure for not
having a uuid in "_alloc_thread_status()" be taken out?

Thank you, 

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Alasdair G Kergon
>Sent: Friday, July 20, 2007 9:26 AM
>To: device-mapper development
>Subject: Re: [dm-devel] Question about dmevents
>
>See http://people.redhat.com/agk/talks/FOSDEM_2005/text41.html for info
>about
>how devices are referenced.
>
>Alasdair
>--
>agk@redhat.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

Re: Question about dmevents

[Alasdair G Kergon]

On Fri, Jul 20, 2007 at 09:57:28AM -0700, Wood, Brian J wrote:
> Hi Alasdair, I also read in the definition of DM_DEV_CREATE that the
> uuid is optional. Since that is the case shouldn't the failure for not
> having a uuid in "_alloc_thread_status()" be taken out?
 
I don't know this code, but in general userspace code should use uuid if it is
present.  If it isn't, it should fall back to using the name.  Whether that
leads to sensible behaviour in this particular case, I don't know.  If it
doesn't then it should be documented that uuid is a requirement.

Alasdair
-- 
agk@redhat.com

RE: Question about dmevents

[Wood, Brian J]

Maybe Jonathan Brassow could shed some light on this :)

Since the documentation says the uuid is optional should this failure
check be modified to a log warning in the "_alloc_thread_status()"
function?


Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Alasdair G Kergon
>Sent: Friday, July 20, 2007 10:14 AM
>To: device-mapper development
>Subject: Re: [dm-devel] Question about dmevents
>
>On Fri, Jul 20, 2007 at 09:57:28AM -0700, Wood, Brian J wrote:
>> Hi Alasdair, I also read in the definition of DM_DEV_CREATE that the
>> uuid is optional. Since that is the case shouldn't the failure for
not
>> having a uuid in "_alloc_thread_status()" be taken out?
>
>I don't know this code, but in general userspace code should use uuid
if it
>is
>present.  If it isn't, it should fall back to using the name.  Whether
that
>leads to sensible behaviour in this particular case, I don't know.  If
it
>doesn't then it should be documented that uuid is a requirement.
>
>Alasdair
>--
>agk@redhat.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

Re: Question about dmevents

[Peter Rockai]

On Fri, Jul 20, 2007 at 06:14:04PM +0100, Alasdair G Kergon wrote:
> On Fri, Jul 20, 2007 at 09:57:28AM -0700, Wood, Brian J wrote:
> > Hi Alasdair, I also read in the definition of DM_DEV_CREATE that the
> > uuid is optional. Since that is the case shouldn't the failure for not
> > having a uuid in "_alloc_thread_status()" be taken out?
>  
> I don't know this code, but in general userspace code should use uuid if it is
> present.  If it isn't, it should fall back to using the name.  Whether that
> leads to sensible behaviour in this particular case, I don't know.  If it
> doesn't then it should be documented that uuid is a requirement.

Yes, the uuid here is a requirement, since it is what is used for
communication between dmeventd and other userspace components. Using
device names is, in my opinion, prone to races and therefore not quite
suitable for dmeventd. Moreover, since the dmeventd -only- gets the
uuid (from whichever other application it tries to get it), it cannot
fall back to name, not knowing it.

In fact, when using theh libdevmapper-event library, the client-side
code should already fail, if a device has no uuid. In practice, this
means that uuid-less devices cannot be monitored, but that is probably
a case that is not really important (or is it?).

I would probably prefer to just document this as requirement and keep
things as they are. Comments?

Yours, Peter.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

Re: Question about dmevents

[Peter Rockai]

On Fri, Jul 20, 2007 at 09:02:18AM -0700, Wood, Brian J wrote:
> After this long setup here's the problem I'm having. I run through the
> remaining function calls in _get_device_info() and my uuid for the
> dm_task is still null. The last call before sending this message off to
> dmeventd using the "_do_event()" is a call to dm_task_get_uuid() that is
> passed my dm_task struct. This should return a uuid string, but returns
> null since my dm_task is never getting a uuid set. Without this I get a
> failure on the dmeventd side stating I passed a null pointer into
> dm_strdup via the function _alloc_thread_status (where it checks the
> uuid field). 

This is indeed a bug in the code, first that libdevmapper-event fails
to check that the uuid it tries to use is valid (ie., it assumes that
whenever dm_task asking DM_DEVICE_INFO succeeds, it has a valid UUID,
which seems to be not the case). This needs fixing, as well as
dmeventd, which apparentlty breaks down on an invalid message (i have
to test this though).

In the meantime, please make sure you are only registering devices
that do have UUID (you don't need to supply it, it just needs to be
there in the device mapper info). In a future version, the code should
fail gracefully in case the UUID is not available.

Yours, Peter.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com
 http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation

Re: Question about dmevents

[Alasdair G Kergon]

On Sun, Jul 22, 2007 at 10:43:17AM +0200, Peter Rockai wrote:
> In fact, when using theh libdevmapper-event library, the client-side
> code should already fail, if a device has no uuid. In practice, this
> means that uuid-less devices cannot be monitored, but that is probably
> a case that is not really important (or is it?).
> I would probably prefer to just document this as requirement and keep
> things as they are. Comments?

That all makes sense to me.

  name = user-friendly reference; can be changed at will
  uuid = software-friendly reference, a constant for the life of the device

If we have existing software not setting up uuids then those programs need
investigating.

Alasdair
-- 
agk@redhat.com

RE: Question about dmevents

[Wood, Brian J]

>-----Original Message-----
>From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On
>Behalf Of Alasdair G Kergon
>Sent: Sunday, July 22, 2007 4:16 AM
>To: device-mapper development
>Subject: Re: [dm-devel] Question about dmevents
>
>On Sun, Jul 22, 2007 at 10:43:17AM +0200, Peter Rockai wrote:
>> In fact, when using theh libdevmapper-event library, the client-side
>> code should already fail, if a device has no uuid. In practice, this
>> means that uuid-less devices cannot be monitored, but that is
probably
>> a case that is not really important (or is it?).
>> I would probably prefer to just document this as requirement and keep
>> things as they are. Comments?
>
>That all makes sense to me.

Agreed :)


>
>  name = user-friendly reference; can be changed at will
>  uuid = software-friendly reference, a constant for the life of the
device
>
>If we have existing software not setting up uuids then those programs
need
>investigating.
>

I have a question though, not being too familiar with the device-mapper
core code. When I load a fresh system using FC7 on a raid1 volume (for
example) I never see a prompt during the installation asking if I would
like to have a UUID assigned. After the install I check and there isn't
one assigned by default. If I then add some disks to the system and
decide to install an LVM2 mirror I do this using the command line and
there is a UUID assigned by default. Is this also a bug in the
installer? Or is there a way I can assign a UUID to an already existing
system? In the documentation it says I would have to delete my volume
group and rebuild it to assign a UUID is this correct? If so how can a
fresh system get a UUID?

Thank you for all the help :) 

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com

>Alasdair
>--
>agk@redhat.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel

Question about device-mapper/raid

[Wood, Brian J]

Hello everyone,

Not being too familiar with the device-mapper core code I have a
question. When I load a fresh system using FC7 on a raid1 volume (for
example) I never see a prompt during the installation asking if I would
like to have a UUID assigned. After the install I check and there isn't
one assigned by default. If I then add some disks to the system and
decide to install an LVM2 mirror I do this using the command line and
there is a UUID assigned by default. Is this also a bug in the
installer? Or is there a way I can assign a UUID to an already existing
system? In the documentation it says I would have to delete my volume
group and rebuild it to assign a UUID is this correct? If so how can a
fresh system get a UUID?

Thank you for all the help :) 

Brian Wood
Intel Corporation 
Digital Enterprise Group
Manageability & Platform Software Division
brian.j.wood@intel.com