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? email@example.com
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'?!!!")
by-path and by-id unsuitable?
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)
- I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:
- 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.
- For example, a device with a page 0x83 identifier would have:
- scsi-3600508b400105e210000900000490000 -> ../../sda
- Or, a device with a page 0x80 identifier would have:
- scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda
- Red Hat Enterprise Linux 5 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.
- Am I missing something?
- Goulo 04:42, 11 January 2012 (EST)