Eugene Vilensky wrote: >> >> Just wondering what sort of impact this has to your system? If the >> paths are gone they won't be used, so what does it matter? >> > > > > Right now I have backgrounded a 'vgscan -v' operation that froze, which has > never happened before. I assume it is trying to scan the /dev/mpath23 device > that is supported by these four downed paths, and I am worried what would > happen if I removed the maps manually while in this state. > > I am surprised there is not an error-return of some kind between vgscan and > dm-multipath if all paths for a particular mpath device are down... Check lsof to see what it's hung on..it's been a while since I've run into that sort of issue.. When I mount volumes I have a special init script that handles it, all of my SAN volumes are LVM, and they have a particular naming scheme so the script can detect them easily, the script is here, perhaps the ideas behind it could be useful for you: http://portal.aphroland.org/~aphro/mount_san.init Sample runs: start- [root at dc1-mysql002b:~]# /etc/init.d/mount_san start Scanning and activating SAN-based volume groups PV /dev/sdc1 is in exported VG san-p-mysql002b-log [1023.99 GB / 983.99 GB free] PV /dev/sdb1 is in exported VG san-p-mysql002b-db [2.00 TB / 1.90 TB free] Total: 2 [3.00 TB] / in use: 2 [3.00 TB] / in no VG: 0 [0 ] Volume group "san-p-mysql002b-log" successfully imported Volume group "san-p-mysql002b-db" successfully imported Checking LVM SAN filesystems.. e2fsck 1.39 (29-May-2006) /dev/san-p-mysql002b-log/san-p-mysql002b-log: clean, 84/10240 files, 391173/10485760 blocks e2fsck 1.39 (29-May-2006) /dev/san-p-mysql002b-db/san-p-mysql002b-db: clean, 353/25600 files, 4633225/26214400 blocks Finished checking LVM SAN filesystems.. Scanning and mounting multipathed filesystems.....[/san/MrT/mysql/db]....[/san/MrT/mysql/log]..done! stop: [root at dc1-mysql002b:~]# /etc/init.d/mount_san stop Scanning and un-mounting multipathed filesystems.....[/san/MrT/mysql/db]....[/san/MrT/mysql/log]..done! Scanning and exporting SAN based volume groups.. Volume group "san-p-mysql002b-log" successfully exported Volume group "san-p-mysql002b-db" successfully exported With CentOS 5.x I had to fix the rc.sysinit to skip the 'noauto' file systems, otherwise the system pukes on boot(wasn't a problem in CentOS 4.x). I originally came up with the script because I needed a way to mount software iSCSI file systems after the network was up and unmount them cleanly before the network went down, RHEL/CentOS 5 introduced better support for this(haven't tried it my system works..), but in 4.x it was an issue, caused I/O hangs on shutdown and prevented file systems from being mounted automatically on boot. Been using this script on many systems for about a year and a half now. I don't recall ever using/needing vgscan myself. The man page for vgimport mentions using it for previously recognized volume groups, but I've used it even for first time volume recognition and it's always worked. nate