Talk:Persistent block device naming
Enabling persistent naming in /etc/fstab is easy, just replace the device name in the first column by the new persistent name. In my example I would replace /dev/sda7 by one of the following:
/dev/disk/by-label/home or /dev/disk/by-uuid/31f8eb0d-612b-4805-835e-0e6d8b8c5591 Do so for all the partitions in your fstab file.
... is this really truely ?
I have to use :
or I understood somewhat wrongly.
- It works, yes. But I prefer LABEL over UUID:
- LABEL=HOME-jfs /home nodev,nosuid,noatime 0 2
- --byte 08:19, 19 December 2006 (EST)
Found this howto easy & very usefull :) Have got a few HDDs & USBKeys that love to be (disk-label) mounted so easy but still a sure way (by easy i mean, compared to udev rules ;).
- --kozaki 15:19, 7 January 2007 (PST)
but I havn't this /dev/disk/by-label directary,why? firstname.lastname@example.org
That's because that directory is actually created (and destroyed) dynamically when you attach (or detach) some disk or partition that has a label! A bit scary for the uninitiated, but true....
- --jf 15:32, 29 March 2007 ("Why couldn't everybody JUST use easily-referenced 'GMT', or 'UTC'?!!!")
the article says by-path is unsuitable because it "contain[s] strings to indicate which subsystem they belong to (i.e. "-ide-", for 'by-path', and "ata-" for 'by-id')"
How does that make it unsuitable? For by-path, that string is the same each boot, because the bus doesn't move (even if the buses get initialized in a different order) -- e.g. suppose you've got two SATA disks, on SATA connector #1 and #2 on your motherboard. #1 may become /dev/sda on one boot, and /dev/sdb the next time. Its by-path name won't change, though -- /dev/disk/by-path/sata-1 will point to /dev/sda in the first case and /dev/sdb in the second case, so it's persistent.
Furthermore, by-path is actually safer than by-label and by-uuid, because those rely on the disk data to identify the disk. Suppose you and a friend both named your boot drive "root". Your friend's power supply blows, so you plug his drive into your eSATA port to retrieve some data for him -- but oops, your system found his "root" label before yours, and suddenly you're trying to boot to the wrong disk. (I've actually tested this, and it can/does happen. It's most likely to happen when something is wrong, e.g. one of your drives is dying -- which is also when you least *want* it to happen.)
Thetrivialstuff 01:04, 13 August 2011 (EDT)