# HELP: udev random naming is a royal pain!

## Moriah

udev pretty much randomly asigns names to hot swappable SATA drives.  This causes no end of confusion when assembling and disassembling RAID arrays.  Is there any way to lock /dev/sda to slot 1, /dev/sdb to slot 2, etc. so that /dev/sdX always has the same physical location.?    :Question: 

Thanks to this random naming problem, I just lost 3 months worth of backups!   :Evil or Very Mad: 

----------

## mahdi1234

You can write your specific UDEV rules to have persistent naming - see e.g. http://www.gentoo-wiki.info/HOWTO_Customizing_UDEV

You could end-up with something like this in your local rules file

```

# USB SAMSUNG 1.5TB

SUBSYSTEM=="block", KERNEL=="sd?",      ATTRS{serial}=="533159364A39305343303334", NAME="usb/usb"

SUBSYSTEM=="block", KERNEL=="sd?[0-9]", ATTRS{serial}=="533159364A39305343303334", NAME="usb/usb%n" 

```

this connects my external drive as /dev /usb/<partition>

----------

## Moriah

OK, I finally got around to trying to set up udev so I can address hot swappable sata drives by their position in the sata backplane instead of by /dev/sda, /dev/sdb, etc...

The wiki article pointed to above is so out of date as to be useless, and the man page was obviously written by the guy who wrote the software, and proofread by no one else, so *HE* knew what he meant, but he left out more than he put in.  Terms are defined circurlarly or not at all, and there are no examples.  For a tool as complicated as udev, this is inexcusable.

This is my biggest gripe about free software -- no quality control at all regarding documentation.  If the software is not accompanied by documentation that is accurate, up to date, and understandable by someone who did not write the code, then the software is only useful to the original author and no one else, and so it should not be released as a production item.  Documentation needs to be tested and debugged just like software does.

So can anybody point me to any udev docs other than the above 2 hopelessly useless documents?    :Question: 

----------

## wcg

The linux-hotplug mailing list looks like one forum of active udev

discussion. That might be a place to ask for the most up-to-date

udev documentation and ask specific udev configuration questions.

Subscribe/unsubscribe:

http://vger.kernel.org/vger-lists.html#linux-hotplug

Most recent archive:

http://marc.info/?l=linux-hotplug&r=1&b=201106&w=2

----------

## Moriah

Thanks a bunch!  I just subscribed to it.  Hopefully they can help me.    :Very Happy: 

BTW Pardon the previous rant, but documentation *IS* important; without it you can't make use of all the effort the author put into the code.    :Embarassed: 

----------

## Hu

Have you considered using the symlinks that udev creates under /dev/disk/by-id and its siblings?  These incorporate properties of the drive or partitions, so they will follow the physical drive, even if you move it to a different SATA port.  These symlinks point back to the block device nodes, so you can use the symlink name in lieu of the short name for the block device.

----------

## Moriah

I have been displaying those links to see what /dev/sd? is in what slot of the backplane, but my desire is to just say /dev/slot? instead.

I don't want those slots to exist unless there is a drive in them, so I thought udev would be able to set up the /dev/slot? names for me, but I am totally baffled by the crummy description in the only docs for udev that I have seen so far.

----------

## Hu

 *Moriah wrote:*   

> I have been displaying those links to see what /dev/sd? is in what slot of the backplane, but my desire is to just say /dev/slot? instead.

 Why?  You should be able to use the long form names anywhere that you need to name a block device, including in the RAID configuration files.  I can see that having /dev/slot* entries would be convenient for an administrator who just wants to check what is plugged in, but the tools should be fine with long form paths.

----------

## Moriah

The problem is that long names are prone to typing mistakes.  

The raid in question is a 3-way raid-1 mirror on a backup server.  It is 3-way so I can fail a drive and remove it to off-line or off-site storage (like the safe deposit box in the vault at the bank) and still have redundancy while a newly added drive regenerates.  Since pulling a drive is a common event, the raid array gets messed with frequently.  The raid is on top of the raw drives, and the raid is then encrypted via luks, and then lvm runs on top of the encrypted raid, and xfs runs in a logical volume on top of that.  There are no partitions anywhere on the raid drives; lvm takes care of that instead.

There is just way too much potential for confusion here, so keeping the fixed position slot names short and meaningful is a very big plus.  Since the whole thing is encrypted, it is started manually after a reboot, so a pass phrase can be entered.  Only the operator knows which slots contain the drives he wants to use to make up the raid, and in some cases there are 2 drives, but usually there are 3.  The actual hardware sata backplane has 5 slots.  One holds the boot drive with the operating system on it, 3 hold the raid, and one is a working slot to run badblocks for new drives before they are put into service, or to mount an old backup drive to access old files without disturbing the live raid backup array.  In this case, the old drive is mounted as a single drive raid1 with the --force option.

By having udev set up the /dev/slot? symlinks, the slots would only appear if a drive was actually present in the slot.  This too helps prevent mistakes.

Presently, all the drives except the boot drive are 2 TB 7200 RPM units, and the backup files are saved on the xfs filesystem thru a user space file-level dedup mechanism, so I typically can store well over a month of backups for my entire network, with a backup of each machine being made every night.

Sure beats tape!    :Very Happy: 

----------

## mahdi1234

Well ...

```

# udevadm info -a -n /dev/sda | grep serial

    ATTRS{serial}=="533159364A39305343303334"

$ cat /etc/udev/rules.d/10-local.rules | grep 533159364A39305343303334

SUBSYSTEM=="block", KERNEL=="sd?",      ATTRS{serial}=="533159364A39305343303334", NAME="usb/usb"

SUBSYSTEM=="block", KERNEL=="sd?[0-9]", ATTRS{serial}=="533159364A39305343303334", NAME="usb/usb%n"

$ ls ls /dev/usb/

usb  usb1  usb2  usb3  usb4

```

is the magic ... you can choose any of the parameters udevadm returns, just make sure it's unique.Last edited by mahdi1234 on Sun Jun 19, 2011 8:28 pm; edited 2 times in total

----------

## Moriah

I'll have to look into that, but serial numbers certainly won't work, because the drives are changed frequently,  but the raid1 survives for a long time.

----------

## Hu

Thanks for the details.  Not only do I now envy your setup, I also understand why persistent names based on individual disks is inappropriate here.  I had assumed a small number of continuously serving drives, with the possibility that they might migrate from one port to another.  I had not considered that drives would be taken offline and replaced on a regular basis, but it makes perfect sense for your purpose.

----------

## Moriah

I have been using an evolving version of this setup since 2000 when 80 GB drives became affordable at about $230.00 US each.  Today I can get 1 TB 5400 rpm drives for $59.95 each, and 2 TB 7200 rpm drives for $109.95 each.  When the raid gets about 90% full, I yank a drive and put it in the safe deposit box.  I then shove in a fresh new drive that has been proofed with badblocks and let the raid regenerate.  I also delete all the bacup sets older than a certain age, to reduce overlap and free up space for new backup sets.  This is better than starting from scratch, as I can always have at least a month of current backups online at all times.  Older files must be retrieved from the safe deposit box, where they are safe from those nasty midwest tornados.  Since the drives are all encrypted, the loss or theft of a backup drive does not jepordize the data they contain.  Because there is always redundancy, data is only lost thru human carelessness, which is the reason to try to make it as simple as possible to operate.

Before I try anything particularly risky, or just if I am feeling nervous, I yank a drive and put it on the shelf for a security blanket.  Even a software bug or hardware failure cannot touch an unplugged drive; just don't drop it!

I currently have complete historical backups for nearly every night since some time in 2007.  Prior to that, everything was IDE, and with the phasing out of IDE in favor of SATA, I have donated the old IDE drives to charity after scrubbing them for security.  I expect to be donating the 1 TB drives in the future, as the 2 TB and larger drives replace them and after the old drives are over 3 years old.

I hope to go to block level dedup in the future, but zfs is too overpowering, and btrfs is still unreliable for this kind of work.  Lessfs would have been a consideration, but for the stupid tokyo-cabinet thing, and slowness.  I might end up writing my own block level dedup layer that will run on top of another filesystem.    :Shocked: 

----------

