Hi Hannes,
On Fri, Jul 20, 2007 at 04:40:11PM +0200, Hannes Reinecke wrote:
> Removing from /dev and /sys in not sufficient, sadly.
> The memory is only released after the last reference has gone.
> So all fd's have to be closed (ie multipathd and the path checkers have
> to have this path disabled) and no device-mapper table must reference it.
Knowing this, the problem is much easier to spot...
> So easiest way is infact to have multipathd run with -v 4, as this will
> tell you exactly if multipathd has stopped the path checker.
> The device-mapper tables can be checked manually with dmsetup.
...it's in multpathd/main.c. The sysfs device is already gone when we
get the remove event. This patch makes it obvious:
diff --git a/multipathd/main.c b/multipathd/main.c
index 5f98c33..00890d7 100644
--- a/multipathd/main.c
+++ b/multipathd/main.c
@@ -635,8 +635,10 @@ uev_trigger (struct uevent * uev, void * trigger_data)
return 0;
sysdev = sysfs_device_get(uev->devpath);
- if(!sysdev)
- return 0;
+ if (!sysdev) {
+ condlog(4, "Devpath '%s' of uevent '%s' vanished", uev->devpath, uev->action);
+ return 0;
+ }
lock(vecs->lock);
Signed-Off-By: Guido Günther <agx@xxxxxxxxxxx>
The sysfs device is already gone, so sysfs_device_get returns 0 and we
never call uev_remove_path further down below. The check of the return
value was added by f1b1fca2ccbfd7d58350eb136105fdaf8aa4f59ca, which is
imho correct. Can we expect the sysfs node to stay around long enough? I
don't think so, so should we cache the sysfs_device structures somewhere
to use them on path removal? I could cook up a patch.
Cheers,
-- Guido
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
