[ale] Kubuntu 13.04 danger: beware /dev/dm-*

Wed May 1 08:46:24 EDT 2013

If you’re using multipathing you can create rules in /etc/multipath.conf to make your device names persistent and use those rather than the dm-* device names.   You can even make the rules based on the UUID so that at short glance you can tell something about the UUID (At least in RHEL5 where I just did it.)

For example I wanted to have persistent names to use in a Hitachi HORCM control file so added the following:

multipaths {
        # 29-Apr-2013 jlightner - Aliases for Hitachi HORCM command devices(CMD)
        #                         NOT in any VG and can NOT be used for data
        multipath {
                wwid                360060e8006d142000000d1420000fe0f
                alias                   hctl1
        }
        multipath {
                wwid                 360060e8006d142000000d1420000fe10
                alias                   hctl2
        }
}

For the rest of my Hitachi devices I wanted to use names that include the last 4 characters of the UUID (WWID) so before the last curly brace above I inserted:
        multipath {
                wwid                360060e8006d142000000d142000025b6
                alias                   hldev25b6
        }
        multipath {
                wwid                 360060e8006d142000000d142000025b7
                alias                   hldev25b7
        }

The reason for using the last 4 characters is for my Hitachi array those always correspond to the CU:LDEV ID  I see within the array itself.   It allows me to write scripts to do vgimportclone using persistent device names for my nightly disk mirroring/splitting (Shadow Image/BCV) process.

On reboot multipath creates the devices in both /dev/mapper and /dev/mpath:

brw-rw---- 1 root disk 253, 37 Apr 29 15:41 /dev/mapper/hctl1
brw-rw---- 1 root disk 253, 38 Apr 29 15:41 /dev/mapper/hctl2

lrwxrwxrwx 1 root root 8 Apr 29 15:41 /dev/mpath/hctl1 -> ../dm-37
lrwxrwxrwx 1 root root 8 Apr 29 15:41 /dev/mpath/hctl2 -> ../dm-38

On another reboot the dm-* device linked on right side in /dev/mpath might have changed but the left side of the link won’t and whatever the dm-* is WILL still be the WWID (UUID) you had defined in multipath.conf.   Note the /dev/dm* device whatever it is will have the same major/minor as see in the /dev/mapper device which is one way to confirm it is what you think it is.   This means you can use either the /dev/mpath/* or the /dev/mapper/* device.

At some point I’ll probably work out a global substitution rule for this kind of thing but at present I’m simply using the scsi_id command to determine WWID (UUID) of the devices and hard coding each into multipath.conf.

From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Jim Kinney
Sent: Tuesday, April 30, 2013 10:17 PM
To: Atlanta Linux Enthusiasts
Subject: Re: [ale] Kubuntu 13.04 danger: beware /dev/dm-*

Sorry to hear about this. UUIDs suck to work with (too long for normal short term memory - too non-associative for long-term memory) but they as certainly stable and definitive.

On Tue, Apr 30, 2013 at 8:42 PM, George Allen <glallen01 at gmail.com<mailto:glallen01 at gmail.com>> wrote:
So, I just finished recovering from a data-loss causing error in the new ubuntu:

I had one hard drive with 12.10, and a new one with a fresh install of 13.04.
Both used LVM, with slightly different custom setups...

In transferring the files from the old to new drives, via rsync and an
external usb adapter, the transfer suddenly errored out after several
GBs.

I don't have the logs handy to give better notes (specific errors),
but basically:
- sometime late in the rsync the computer decided to write something to swap.
- 13.04 had created the cryptswap device using /dev/dm-3 instead of
/dev/mapper/vg-swap or a UUID (in /etc/crypttab)
- sometime in my modifying the partitions/lvm and adding a usb drive
that also contained lvm volumes, /dev/dm-* were re-numbered

So as soon as the computer touched swap, it corrupted my /dev/vg/home
logical volume

It took me a while to figure out what was going on... then with blkid
and lots of googling I managed to find out by comparing UUIDs for each
device.

To avoid further problems - grep -rE '/dev/(sd.|mapper|disk|dm)' * on
both systems confirmed that '/etc/crypttab' on the 13.04 install was
the only important file that referenced anything by dm-* but that one
file can hose your system if somehow dmsetup renumbers things after
changes.

-George

_______________________________________________
Ale mailing list
Ale at ale.org<mailto:Ale at ale.org>
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo

--
--
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you gain at one end you lose at the other. It's like feeding a dog on his own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://electjimkinney.org
http://heretothereideas.blogspot.com/

Athena®, Created for the Cause™

Making a Difference in the Fight Against Breast Cancer

How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative to beverages that contain sugar, calories, etc. Your support of bottled water will make a difference! Your signatures count! Go to http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a petition to support your right to always choose bottled water. Help fight federal and state issues, such as bottle deposits (or taxes) and organizations that want to ban the sale of bottled water. Support community curbside recycling programs. Support bottled water as a healthy way to maintain proper hydration. Our goal is 50,000 signatures. Share this petition with your friends and family today!

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130501/e52d217e/attachment-0001.html>