This is a continuation of my work on getting open-iscsi working on etch and then getting dm_multipath working.
Note that I have the pass column in the fstab set to 0 so the system won’t fail to boot when fstab can’t find this partition early in the boot process; this is important.
I started off trying to use _netdev as a mount option. I verified in ‘/etc/init.d/mountall.sh’ that debian does use mount -a -O no_netdev to avoid mounting network devices before networking is up, but while watching the startup (vmware is great for this) I saw it was still trying to mount early in the boot process anyways, and the UUID wasn’t there yet, of course, since iscsi and networking weren’t there yet.
I took a look in the initrd (‘mkdir /tmp/initrd ; cd /tmp/initrd ; cat /boot/initrd.img-`uname -r` | cpio -idmv’) in search of where it reads the fstab to see if that was the same case and saw that ‘scripts/local-top/iscsi’ definitely was trying to get iscsi things done. It’s worth noting this may not have been there if I hadn’t recreated my initrd recently in my last post. I recalled seeing some notes about root on iscsi in ‘/usr/share/doc/open-iscsi/README.Debian’ (comes with the open-iscsi deb).
Someone I got an additional node that produced an error about failing to log in since it already existed. I stopped the open-iscsi init script and removed the corresponding folder in the /etc/iscsi/nodes/ tree, then restarted open-iscsi. It caught my eye that this script reported ‘Mounting network filesystems’ so I looked in the script and on line 102 saw ‘mount -a -O _netdev’ to mount lines tagged with the ‘_netdev’ option. On reviewing my fstab I saw I had two mounts, one commended out using /dev/dm-1 and the other not commented out using the UUID. The UUID mount was using ‘defaults’ while the devmapper mount was using ‘_netdev’. I switched the UUID mount to use the _netdev option, rebooted and saw my filesystem mounted. I ran ‘rm /etc/iscsi/iscsi.initramfs’ to rensure that my onboot initramfs work didn’t make a difference and it was confirmed.
The trick is simply to set your fstab up using the UUID (use ‘blkid’ to get it), options set to ‘_netdev’ and pass set to ‘0’:
UUID=8d070de0-403c-4669-9db0-5b17e3aeebc5 /mnt ext3 _netdev 0 0
Of course the ext3 partition won’t get fscked on startup, but that’s just the filesystem I was using for testing. The ultimate goal is to use GFS or OCFS or something to create an iscsi volume fronted by NFS on multiple servers.
So the open-iscsi init.d script actually does the mounting that finally works. This is mentioned in this group thread, although it’s worth noting that I set ‘node.startup = automatic’ and left ‘node.conn[0].startup = manual’ on each node. I don’t know what the difference is. In response to this later thread, I did not have to use an extra script.
Other options are persistent udev rules. http://kbase.redhat.com/faq/FAQ_103_12118.shtm
Or labels, tune2fs -L then LABEL=foo in your fstab. GFS has labels, I imagine OCFS2 does as well.
If you’re going to be using multipath you can do it there too.
I think all of these should work on debian systems.
When you changed the preferred path on the MD3000i do you observer I/O errors during the trespass? We are using this configuration to expose disks to oracle ASM in our test and qa environments and don’t want to see I/O errors should a controller fail. Is multipathd capable of handling the transition and basically holding the disk requests off until the transition has been made?
@Jim
I did see I/O errors but they were from the nodes on the old path failing. I had no problems with accessing the data through the multipath device, but I haven’t tried running bonnie++ against the multipath device while failing over the controller. I assume that the device created by multipath will throw I/O errors if all the devices behind it go away.
I see some errors in your configuration. The problem is that you are using readsector0 for path checking instead of RDAC and a wrong hwhandler. You have to setup multipath.conf with a working configuration. Have a look at http://www3.dslreports.com/shownews/Benchmarking-the-MD3000-powervault-under-linux-87401 for an example configuration. It worked in my situation.