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@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@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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
