On Wed, 22 Jun 2005 00:58:53 +0200 christophe varoqui <christophe.varoqui@xxxxxxx> wrote > Now you also have the CLI facility to remove checkers while keeping the > daemon online. That or restarting the daemon or sending a SIGHUP (not > implemented right now) seem legitimate to me when an admin changes a > config file. Isn't it ? Yes, I like the SIGHUP idea best. I'm not sure what you mean by "CLI facility to remove checkers". > > (3) After experimenting with this stuff on my SuSE SLES 9 > SP2 host, while > > trying to run > > performance tests I got myself into a situation where a > multipath mapped > > device file referred > > to THE WRONG LU. I had no idea this was happening until I > researched why > > dd(1) was > > writing only half the number of 4kb records to the LU than > was a dd(1) to > > the native scsi > > device path. > > > > This happened because it appears that symbolic links in > /dev/disk/by-name to > > device > > mapper device files in /dev are NOT cleaned up as a result > of running > > "multipath -F", > > "dmsetup remove <map-name>, or "dmsetup remove_all". A subsequent > > invocation of > > multipath will not necessarily assign multipath mapped > devices to the same > > device mapper > > minor instances (for example, if one or more of them are > blacklisted after > > the remove step) > > causing the stale symbolic links in /dev/disk/by-name to > refer to the wrong > > dm-<minor> > > device file in /dev. > > > > An invocation of "multipath -F" did cleanup device files in > /dev on my Red > > Hat AS 4 host > > but an invocation of "dmsetup remove <map-name>" did not. > I was loath to > > experiment > > with "dmsetup remove_all" on my Red Hat host since my root > device on that > > host is on > > a device mapper LVM2 logical volume. Otherwise, I suspect > that this command > > would > > fail to clean up device files in the same way "dmsetup > remove_all" failed. > > > I'll wait for you to pin down this problem. I was hoping Alasdair or Lars would comment first :))
