> -----Original Message----- > From: Alasdair G Kergon [mailto:agk@xxxxxxxxxx] > Sent: Thursday, November 10, 2005 6:22 PM > To: goggin, edward > Cc: 'dm-devel@xxxxxxxxxx' > Subject: Re: patch to dm.c to delay add_disk call > for new mapped device till a fter device's map is loaded > > On Thu, Nov 10, 2005 at 01:53:53PM -0500, goggin, edward wrote: > > Patch to dm.c to delay the add_disk call for a newly > created mapped device > > until after the mapped device's map is loaded for the first > time in dev_load > > so that an a hotplug/uevent handler will not fail to > acquire information > > about > > the mapped device's map. > > I'm not keen on this one yet - I can see the problem, but > uevent is asynchronous > so I'm not sure where the right place to fix this is. I'm not either. > [By the time the handler runs, anything could have happened > to the device's > state - the device could even have been deleted. So when the > handler runs it > can make *no* assumptions about the state of the device. > Particularly as > uevents can get lost.] I don't disagree with any of this. But, without this change or something like it, a call to dm to get information about the mapped device associated with a uevent add event can fail even without any of these atypical occurrences. How is the uevent handling code to differentiate one of the cases you describe above from the case my patch is trying to fix. It is difficult to do without writing code to delay and retry on error. This is ugly code and must be written in every uevent handler for these events. > > If the handler wants to know what type of table, then it > should be notified > every time a new table goes live - separately from when the > device is created. I see that as a different issue. This change is to enable a uevent handler to deterministically tell if a one of the conditions you cite above occurred (device was deleted before uevent handler got to call into dm) without sleeping and retrying. > > If the uuid holds the 'creating subsystem' as a prefix then > that's sufficient to > identify it as multipath or EVMS or LVM2 etc. rather than > looking for a map. > > And for snapshots, issuing a uevent when a table is activated > may risk problems > - it needs thinking through. > > Alasdair > -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
