Hacker News Reader

Comment by isodude | Hacker News Reader

We had that kind of problem because we relied on /dev/disks/by-label

Can you tell us more about this? How did you determine that that was the problem? What was your solution?

I ask because I use /dev/disks/by-label and have never had this problem, and if I ever had to experience it, it would drive me insane.

I've solved a similarly sounding issue by using the UUID. Get it with blkid, then use UUID="<uuid goes here>" in fstab instead of LABEL="<label>".

But this was a long time ago, on a much older systemd (like Fedora 17 or 18).

This is a common error even back in the Sysvinit days. /dev/disks/by-label is not guaranteed to map the name labels to disks on every boot, and it can change with boot timing based on the storage controller behavior. Use /dev/disks/by-uuid instead.

/dev/disks/by-label is a legacy from the old days of systems with static disks wired in a specific, unchanging configuration.

You've confused by-label with the kernel's device nodes (e.g. /dev/sda1). Kernel names are assigned in order. Labels are just like UUIDs and part of the filesystem.

However, unlike UUIDs they don't necessarily exist, are not as likely to be unique (you should only get duplicate UUIDs by cloning filesystems) and are easier to change. This makes them less suitable for mount configuration.

Long time ago now, but we had disks just unmounting and mounting at free will.

As someone said by-label is not stable and could be changed, causing problems. We still use it though but not in customer facing servers where these problems arise. Maybe related to lvm/snapshot etc.

Reply on news.ycombinator.com