Talk:Persistent block device naming
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)
- I don't know if this could be relevant, at least in the context of using by-id with GRUB on BIOS computers: https://savannah.gnu.org/bugs/index.php?35354#comment3 --Kit (talk) 17:49, 25 October 2012 (UTC)
- It seems to me that /dev/disk/by-id is a perfectly suitable solution for persistent block device naming, since it is guaranteed to uniquely identify a device and is agnostic to varying assignment of device node names and, in most cases, to which system bus the device is attached. I can't speak for by-path. DPiergies (talk) 23:41, 13 May 2015 (UTC)
Problems with labels
- I can see further problems with this article. Neither disk nor partition labels can be guaranteed to be unique across a system. Indeed, some file systems, notably btrfs and ZFS, will (quite legitimately) assign the same labels to disks and partitions under their control. In such a setup, /dev/disk/by-label and /dev/disk/by-partlabel cannot be used. The assumption that such labels will be unique has also caused problems with systemd, according to this this thread. I have added accuracy markers to those sections as well. DPiergies (talk) 23:41, 13 May 2015 (UTC)
- (I separate your last paragraph into a new item, because the first item gets too complex. I will fix the templates you added to point to this item).
- I agree with you (though I don't have ZFS experience, I am sure it holds true). I believe we need to add to the sections to make aware of these filesystems' designs. Separate from that I think we should add a warning regarding systemd, because (at least for btrfs) it has regressions that should be mentioned in this context.FS#42884 
- --Indigo (talk) 12:06, 14 May 2015 (UTC)