Udev & external devices (persistent device names)
UDEV allows Linux users to have a dynamic /dev directory and it provides the ability to have persistent device names. Persistent device names prevent having to remember if the device was /dev/sda , or /dev/sdb1 etc, very handy for temporary devices such as USB flash drives and so on. If you wanted to use FSTAB to allow users to mount devices you could just forget it because none of the devices had the same reference name ~ ergo FSTAB was useless for this.
I presume that UDEV is installed and working, as I am not going to explain how to install it.
Detecting your device
Since my all external devices are USB2 based and compatible with Linux its was matter of digging in kernel to make them work with my system. Same rule goes here as for UDEV installation. I don’t know what hardware you have and can’t help you with it, you need to worked that out for your self. This howto is based on hardware that I have and it should apply to most of the hardware out there. So first thing is to make them work with out UDEV and then install UDEV and make them work together.
We are going to use udevinfo to find out information about our devices. Let’s start figuring out where my USB drive is. Just to remind you almost all devices connected over USB can be found as /dev/sd*
will show you information on devices that are connected to PC over USB2. After running command few times on different devices I found out that USB is connected as /dev/sdc . Here is SYSFS output:
Simplify the output
There is lots of info here and we are going to use just one of them, so don’t let this scare you. To simplify the output:
So “USB2.0 Storage Device” is the one thing we are going to use and add it to udev rule later on.
The other device that I want to add is my LEXAR USB2 Card-reader that can read 4-5 different memory cards. Process of finding out where the device is, is the same as for USB drive only you have to remember that this device is seen as 4 different devices.
Let’s start finding out this to shall we? We can eliminate sdc because its already in use for USB drive. So running:
until you find all of yours slots.
and look for card type explanation
and look for SYSFS=="Media Inc. SD " where SD is for secure digital
and look for SYSFS=="Media Inc. SM/xD" where SM/xD is for Smart media xD-picture card
and look for SYSFS=="Media Inc. MS " where MS is for memory stick.
UDEV rules
We have now all that we need of information that’s going to be added to udev rules. The configuration file is going to be placed in /etc/udev/rules.d/ and we are going to call it 10-udev-early.rules. There are some other files in this directory but we are not going to use or change anything in them.
The number in front of the name of config file is actually telling the system which of all config files in this directory is going to be read first, 5 before 10 and 10 before 50 and so on. So after making new file called 10-udev-early.rules open it in your favorite text editor (for me its nano) and add following lines.
What does this all mean you ask ? Its self explainable but here are some guidelines about it
After adding things to out conf file we are ready to reload rules for udev and that we can do like this:
after which you are going to have symlinks for your devices in your /dev/
Now simple mount /dev/CF /mnt/cf is going to mount your CF card to /mnt/cf .
Adding to fstab
To make it even more simple and make it so that users can mount devices self let’s add them to /etc/fstab
So now simple mount /dev/usbdisk will mount your usb drive to /mnt/usbdisk
UPDATE: I recently bought a new 250 GB drive which I split into 3 parts, making 3 vfat partitions for my files and other things 🙂 Why vfat you ask? Because I am going to use this both on Linux and Windows. Having 3 partitions on my usb drive presented a problem for usb-drive line in UDEV rules. It took me a while to figure out this and here is solution.
You can make group storage and add your self to it but I think it works with out it too.
25.8. Persistent Naming
Red Hat Enterprise Linux provides a number of ways to identify storage devices. It is important to use the correct option to identify each device when used in order to avoid inadvertently accessing the wrong device, particularly when installing to or reformatting drives.
25.8.1. Major and Minor Numbers of Storage Devices
Storage devices managed by the sd driver are identified internally by a collection of major device numbers and their associated minor numbers. The major device numbers used for this purpose are not in a contiguous range. Each storage device is represented by a major number and a range of minor numbers, which are used to identify either the entire device or a partition within the device. There is a direct association between the major and minor numbers allocated to a device and numbers in the form of sd[ number(s) ] . Whenever the sd driver detects a new device, an available major number and minor number range is allocated. Whenever a device is removed from the operating system, the major number and minor number range is freed for later reuse.
The major and minor number range and associated sd names are allocated for each device when it is detected. This means that the association between the major and minor number range and associated sd names can change if the order of device detection changes. Although this is unusual with some hardware configurations (for example, with an internal SCSI controller and disks that have their SCSI target ID assigned by their physical location within a chassis), it can nevertheless occur. Examples of situations where this can happen are as follows:
A disk may fail to power up or respond to the SCSI controller. This will result in it not being detected by the normal device probe. The disk will not be accessible to the system and subsequent devices will have their major and minor number range, including the associated sd names shifted down. For example, if a disk normally referred to as sdb is not detected, a disk that is normally referred to as sdc would instead appear as sdb .
A SCSI controller (host bus adapter, or HBA) may fail to initialize, causing all disks connected to that HBA to not be detected. Any disks connected to subsequently probed HBAs would be assigned different major and minor number ranges, and different associated sd names.
The order of driver initialization could change if different types of HBAs are present in the system. This would cause the disks connected to those HBAs to be detected in a different order. This can also occur if HBAs are moved to different PCI slots on the system.
Disks connected to the system with Fibre Channel, iSCSI, or FCoE adapters might be inaccessible at the time the storage devices are probed, due to a storage array or intervening switch being powered off, for example. This could occur when a system reboots after a power failure, if the storage array takes longer to come online than the system take to boot. Although some Fibre Channel drivers support a mechanism to specify a persistent SCSI target ID to WWPN mapping, this will not cause the major and minor number ranges, and the associated sd names to be reserved, it will only provide consistent SCSI target ID numbers.
These reasons make it undesirable to use the major and minor number range or the associated sd names when referring to devices, such as in the /etc/fstab file. There is the possibility that the wrong device will be mounted and data corruption could result.
Occasionally, however, it is still necessary to refer to the sd names even when another mechanism is used (such as when errors are reported by a device). This is because the Linux kernel uses sd names (and also SCSI host/channel/target/LUN tuples) in kernel messages regarding the device.
25.8.2. World Wide Identifier (WWID)
The World Wide Identifier (WWID) can be used in reliably identifying devices. It is a persistent, system-independent ID that the SCSI Standard requires from all SCSI devices. The WWID identifier is guaranteed to be unique for every storage device, and independent of the path that is used to access the device.
This identifier can be obtained by issuing a SCSI Inquiry to retrieve the Device Identification Vital Product Data (page 0x83 ) or Unit Serial Number (page 0x80 ). The mappings from these WWIDs to the current /dev/sd names can be seen in the symlinks maintained in the /dev/disk/by-id/ directory.
Example 25.4. WWID
scsi-3600508b400105e210000900000490000 -> ../../sda
scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
Red Hat Enterprise Linux automatically maintains the proper mapping from the WWID-based device name to a current /dev/sd name on that system. Applications can use the /dev/disk/by-id/ name to reference the data on the disk, even if the path to the device changes, and even when accessing the device from different systems.
If there are multiple paths from a system to a device, DM Multipath uses the WWID to detect this. DM Multipath then presents a single "pseudo-device" in the /dev/mapper/wwid directory, such as /dev/mapper/3600508b400105df70000e00000ac0000 .
The command multipath -l shows the mapping to the non-persistent identifiers: Host:Channel:Target:LUN , /dev/sd name, and the major:minor number.
3600508b400105df70000e00000ac0000 dm-2 vendor,product [size=20G][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:1:1 sdc 8:32 [active][undef] \_ 6:0:1:1 sdg 8:96 [active][undef] \_ round-robin 0 [prio=0][enabled] \_ 5:0:0:1 sdb 8:16 [active][undef] \_ 6:0:0:1 sdf 8:80 [active][undef]
DM Multipath automatically maintains the proper mapping of each WWID-based device name to its corresponding /dev/sd name on the system. These names are persistent across path changes, and they are consistent when accessing the device from different systems.
When the user_friendly_names feature (of DM Multipath ) is used, the WWID is mapped to a name of the form /dev/mapper/mpathn . By default, this mapping is maintained in the file /etc/multipath/bindings . These mpathn names are persistent as long as that file is maintained.
If you use user_friendly_names , then additional steps are required to obtain consistent names in a cluster. Refer to the Consistent Multipath Device Names in a Cluster section in the DM Multipath book.
In addition to these persistent names provided by the system, you can also use udev rules to implement persistent names of your own, mapped to the WWID of the storage.