Logical volumes are symlinks instead of block devices

FonHN · 09-20-2011, 06:12 PM

Hi,

I'm setting up a backup agent on a recent Linux install (CentOS 6) and the backup server wouldn't recognize my logical volumes. Instead, it recognizes the following:
/dev/dm-0
/dev/dm-1
/dev/dm-2
/dev/dm-3
/dev/dm-4
/dev/dm-5
Normally the backup server would show the Logical Volumes under the Volume Group, like so:
/dev/mapper/VolGroup1-LogVol_home
/dev/mapper/VolGroup1-LogVol_root

So, in searching for the difference between this and other set ups, I came accross the following. The messed up box yields:

# ls -lah /dev/mapper/VolGroup1-*
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-LogVol_home -> ../dm-5
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-LogVol_root -> ../dm-1
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-LogVol_tmp -> ../dm-4
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-LogVol_usr -> ../dm-2
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-LogVol_var -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 20 13:57 /dev/mapper/VolGroup1-swap -> ../dm-0

While a working box yields:
# ls -lah /dev/mapper/VolGroup1-*
brw-rw---- 1 root disk 253, 3 Sep 12 08:15 /dev/mapper/VolGroup1-LogVol_home
brw-rw---- 1 root disk 253, 0 Sep 12 08:15 /dev/mapper/VolGroup1-LogVol_root
brw-rw---- 1 root disk 253, 5 Sep 12 08:14 /dev/mapper/VolGroup1-LogVol_shm
brw-rw---- 1 root disk 253, 2 Sep 12 08:15 /dev/mapper/VolGroup1-LogVol_tmp
brw-rw---- 1 root disk 253, 1 Sep 12 08:15 /dev/mapper/VolGroup1-LogVol_usr
brw-rw---- 1 root disk 253, 4 Sep 12 08:15 /dev/mapper/VolGroup1-LogVol_var
brw-rw---- 1 root disk 253, 6 Sep 12 08:14 /dev/mapper/VolGroup1-swap

For some reason the Logical Volumes on the CentOS6 box were set up as symlinks to dm-* which are block devices. The correct box has no /dev/dm-* entries and the Logical Volumes are themselves block devices.

Can I fix this online or will I need a maintenance window? And how do I fix this?

Thanks for your help. If you need more information to help me out, please feel free to ask.

tommylovell · 09-20-2011, 09:25 PM

I think you are looking at a fundamental change in how the system works.

All of the RHEL6/Fedora 15/Fedora 14 systems that I looked at have the /dev/mapper/<vg>-<lv> and /dev/<vg>/<lv> devices defined as symlinks pointing to a /dev/dm-n block device. (Older systems do not. They look the way your "correct" systems do.)

Look in the Centos equivalent to

Red Hat Enterprise Linux 6
Logical Volume Manager Administration
LVM Administrator Guide

Edition 1

http://docs.redhat.com/docs/en-US/Re...device_manager

In Table A.1. udev Rules for Device-Mapper Devices

The decription of filename 10-dm.rules says:

Quote:

Contains basic/general Device Mapper rules and creates the symlinks in /dev/mapper with a /dev/dm-N target where N is a number assigned dynamically to a device by the kernel (/dev/dm-N is a node)

NOTE: /dev/dm-N nodes should never be used in scripts to access the device since the N number is assigned dynamically and changes with the sequence of how devices are activated. Therefore, true names in the /dev/mapper directory should be used. This layout is to support udev requirements of how nodes/symlinks should be created.

And the description of filename 11-dm-lvm.rules says:

Quote:

Contains rules applied for LVM devices and creates the symlinks for the volume group's logical volumes. The symlinks are created in the /dev/vgname directory with a /dev/dm-N target.

NOTE: To be consistent with the standard for naming all future rules for Device Mapper subsystems, udev rules should follow the format 11-dm-subsystem_name.rules. Any libdevmapper users providing udev rules as well should follow this standard.

I think that's just the way it is now and there is no way to "correct it" unless you create your own udev rules.

syg00 · 09-26-2011, 02:17 AM

Interesting read. About time dm and LVM (and now udev) integration was progressed.
Too little too late IMHO - having it all (properly) handled by the filesystem is the way of the future. ZFS and btrfs for example. Yeah, yeah I know - btrfs ain't ready for production ...

For the OP, that looks like a broken design on your backup suite - exposed by this change to udev.