https://wiki.archlinux.org/api.php?action=feedcontributions&user=DPiergies&feedformat=atomArchWiki - User contributions [en]2024-03-28T14:28:56ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373606Talk:Persistent block device naming2015-05-13T23:41:33Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
: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.<br />
<br />
: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 [https://bbs.archlinux.org/viewtopic.php?id=196640 this thread]. I have added accuracy markers to those sections as well. [[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:41, 13 May 2015 (UTC)</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373605Talk:Persistent block device naming2015-05-13T23:41:13Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
: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.<br />
<br />
: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 [https://bbs.archlinux.org/viewtopic.php?id=196640 this thread]. I have added accuracy markers to those sections as well.<br />
[[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:25, 13 May 2015 (UTC)</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373604Talk:Persistent block device naming2015-05-13T23:40:13Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
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.<br />
<br />
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 [https://bbs.archlinux.org/viewtopic.php?id=196640 this thread]. I have added accuracy markers to those sections as well.<br />
[[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:25, 13 May 2015 (UTC)</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373603Talk:Persistent block device naming2015-05-13T23:37:50Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
It seems to me that /dev/disk/by-id is a perfectly suitable 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 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 [https://bbs.archlinux.org/viewtopic.php?id=196640 this thread]. I have added accuracy markers to those sections as well.<br />
[[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:25, 13 May 2015 (UTC)</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373602Talk:Persistent block device naming2015-05-13T23:36:51Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
It seems to me that /dev/disk/by-id is a perfectly suitable 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 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 [https://bbs.archlinux.org/viewtopic.php?id=196640 this thread].<br />
[[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:25, 13 May 2015 (UTC)</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=373601Persistent block device naming2015-05-13T23:31:54Z<p>DPiergies: /* by-partlabel */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:File systems]]<br />
[[Category:Hardware detection and troubleshooting]]<br />
[[es:Persistent block device naming]]<br />
[[it:Persistent block device naming]]<br />
[[zh-cn:Persistent block device naming]]<br />
{{Related articles start}}<br />
{{Related|fstab}}<br />
{{Related|udev}}<br />
{{Related|LVM}}<br />
{{Related articles end}}<br />
This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like {{ic|/dev/'''sda'''}} and {{ic|/dev/'''sdb'''}} switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.<br />
{{Note|If you are using [[LVM|LVM2]], this article is not relevant as LVM takes care of this automatically.}}<br />
<br />
==Persistent naming methods==<br />
<br />
There are four different schemes for persistent naming: [[#by-label|by-label]], [[#by-uuid|by-uuid]], [[#by-id and by-path|by-id and by-path]]. For those using disks with [[GUID Partition Table|GUID Partition Table (GPT)]], two additional schemes can be used [[#by-partlabel|by-partlabel]] and [[#by-partuuid|by-partuuid]]. You can also use [[#Static device names with Udev|static device names by using Udev]].<br />
<br />
The following sections describes what the different persistent naming methods are and how they are used. <br />
<br />
The {{ic|lsblk -f}} command can be used for viewing graphically the first persistent schemes:<br />
<br />
{{hc|$ lsblk -f|<nowiki><br />
NAME FSTYPE LABEL UUID MOUNTPOINT<br />
sda <br />
├─sda1 vfat CBB6-24F2 /boot<br />
├─sda2 ext4 SYSTEM 0a3407de-014b-458b-b5c1-848e92a327a3 /<br />
├─sda3 ext4 DATA b411dc99-f0a0-4c87-9e05-184977be8539 /home<br />
└─sda4 swap f9fe0b69-a280-415d-a03a-a32752370dee [SWAP]<br />
</nowiki>}}<br />
<br />
For those using [[GUID Partition Table|GPT]], use the {{ic|blkid}} command instead. The latter is more convenient for scripts, but more difficult to read.<br />
<br />
{{hc|$ blkid|<nowiki><br />
/dev/sda1: UUID="CBB6-24F2" TYPE="vfat" PARTLABEL="EFI SYSTEM PARTITION" PARTUUID="d0d0d110-0a71-4ed6-936a-304969ea36af" <br />
/dev/sda2: LABEL="SYSTEM" UUID="0a3407de-014b-458b-b5c1-848e92a327a3" TYPE="ext4" PARTLABEL="GNU/LINUX" PARTUUID="98a81274-10f7-40db-872a-03df048df366" <br />
/dev/sda3: LABEL="DATA" UUID="b411dc99-f0a0-4c87-9e05-184977be8539" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7280201c-fc5d-40f2-a9b2-466611d3d49e" <br />
/dev/sda4: UUID="f9fe0b69-a280-415d-a03a-a32752370dee" TYPE="swap" PARTLABEL="SWAP" PARTUUID="039b6c1c-7553-4455-9537-1befbc9fbc5b"<br />
</nowiki><br />
}}<br />
<br />
===by-label===<br />
{{Accuracy|Elements provided in the [[Talk:Persistent_block_device_naming|Talk page]] suggest that /dev/disk/by-label and /dev/disk/by-partlabel may not be suitable for persistent naming in certain configurations, particularly if using [[btrfs]] or [[ZFS]]}}<br />
Almost every filesystem type can have a label. All your partitions that have one are listed in the {{ic|/dev/disk/by-label}} directory. This directory is created and destroyed dynamically, depending on whether you have partitions with labels attached.<br />
<br />
{{hc|$ ls -l /dev/disk/by-label|<nowiki> <br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 DATA -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 SYSTEM -> ../../sda2<br />
</nowiki>}}<br />
<br />
The labels of your filesystems can be changed. Following are some methods for changing labels on common filesystems:<br />
<br />
; swap : {{ic|swaplabel -L <label> /dev/XXX}} using {{pkg|util-linux}}<br />
; ext2/3/4 : {{ic|e2label /dev/XXX <label>}} using {{pkg|e2fsprogs}}<br />
; btrfs : {{ic|btrfs filesystem label /dev/XXX <label>}} using {{pkg|btrfs-progs}}<br />
; reiserfs : {{ic|reiserfstune -l <label> /dev/XXX}} using {{pkg|reiserfsprogs}}<br />
; jfs : {{ic|jfs_tune -L <label> /dev/XXX}} using {{pkg|jfsutils}}<br />
; xfs : {{ic|xfs_admin -L <label> /dev/XXX}} using {{pkg|xfsprogs}}<br />
; fat/vfat : {{ic|dosfslabel /dev/XXX <label>}} using {{pkg|dosfstools}}<br />
; fat/vfat : {{ic|mlabel -i /dev/XXX ::<label>}} using {{pkg|mtools}}<br />
; ntfs : {{ic|ntfslabel /dev/XXX <label>}} using {{pkg|ntfs-3g}}<br />
<br />
{{Note|<br />
* Changing the filesystem label of the root partition has to be done from a "live" GNU/Linux distribution because the partition needs to be unmounted first.<br />
* Labels have to be unambiguous to prevent any possible conflicts;<br />
* Labels can be up to 16 characters long.}}<br />
<br />
===by-uuid===<br />
<br />
[[wikipedia:UUID|UUID]] is a mechanism to give each filesystem a unique identifier. These identifiers are generated by filesystem utilities (e.g. {{ic|mkfs.*}}) when the partition gets formatted and are designed so that collisions are unlikely. All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID. FAT and NTFS filesystems (''fat'' and ''windows'' labels above) do not support UUID, but are still listed in {{ic|/dev/disk/by-uuid}} with a shorter UID (unique identifier):<br />
<br />
{{hc|$ ls -l /dev/disk/by-uuid/|<br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 0a3407de-014b-458b-b5c1-848e92a327a3 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 b411dc99-f0a0-4c87-9e05-184977be8539 -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 CBB6-24F2 -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 f9fe0b69-a280-415d-a03a-a32752370dee -> ../../sda4<br />
}}<br />
<br />
The advantage of using the UUID method is that it is much less likely that name collisions occur than with labels. Further, it is generated automatically on creation of the filesystem. It will, for example, stay unique even if the device is plugged into another system (which may perhaps have a device with the same label). <br />
<br />
The disadvantage is that UUIDs make long code lines hard to read and break formatting in many configuration files (e.g. fstab or crypttab). Also every time a partition is resized or reformatted a new UUID is generated and configs have to get adjusted (manually).<br />
<br />
{{Tip|In case your swap partition does not have an UUID assigned, you will need to reset the swap partition using [[Swap#Swap partition|mkswap]] utility.}}<br />
<br />
===by-id and by-path===<br />
{{Accuracy|Elements provided in the [[Talk:Persistent_block_device_naming|Talk page]] (since 2011) seems to clearly indicate that {{ic|by-id}} and {{ic|by-path}} are valid ways to state persistent device names. Were they not, this section should be marked for deletion so as to not bring up confusion in this page dedicated to ''persistent device naming''.|section=by-path and by-id unsuitable?}}<br />
{{ic|by-id}} creates a unique name depending on the hardware serial number, {{ic|by-path}} depending on the shortest physical path (according to sysfs). Both contain strings to indicate which subsystem they belong to (i.e. {{ic|-ide-}} for {{ic|by-path}}, and {{ic|-ata-}} for {{ic|by-id}}) and thus are not suitable for solving the problems mentioned in the beginning of this article. They will not be discussed any further here.<br />
<br />
===by-partlabel===<br />
{{Accuracy|Elements provided in the [[Talk:Persistent_block_device_naming|Talk page]] suggest that /dev/disk/by-label and /dev/disk/by-partlabel may not be suitable for persistent naming in certain configurations, particularly if using [[btrfs]] or [[ZFS]]}}<br />
{{Note|This method only concerns disks with [[GUID Partition Table|GUID Partition Table (GPT)]].}}<br />
<br />
Partition labels can be defined in the header of the partition entry on GPT disks.<br />
<br />
See also [[Wikipedia:GUID_Partition_Table#Partition_entries]].<br />
<br />
This method is very similar to the [[#by-label|filesystem labels]], excepted that the dynamic directory is {{ic|/dev/disk/by-partlabel}}.<br />
<br />
{{hc|ls -l /dev/disk/by-partlabel/|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 EFI\x20SYSTEM\x20PARTITION -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 GNU\x2fLINUX -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 HOME -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 SWAP -> ../../sda4<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* GPT partition labels have also to be different to avoid conflicts. To change your partition label, you can use {{ic|gdisk}} or the ncurse-based version {{ic|cgdisk}}. Both are available from the {{Pkg|gptfdisk}} package. See [[Partitioning#Partitioning_tools]].<br />
* According to the specification, GPT partition labels can be up to 72 characters long.}}<br />
<br />
===by-partuuid===<br />
{{Note|This method only concerns disks with [[GUID Partition Table|GUID Partition Table (GPT)]].}}<br />
<br />
Like [[#by-partlabel|GPT partition labels]], GPT partition UUID are defined in the partition entry on GPT disks. <br />
<br />
See also [[Wikipedia:GUID_Partition_Table#Partition_entries]].<br />
<br />
The dynamic directory is similar to other methods and, like [[#by-uuid|UUID filesystems]], using UUIDs is prefered over labels.<br />
<br />
{{hc|ls -l /dev/disk/by-partuuid/|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 039b6c1c-7553-4455-9537-1befbc9fbc5b -> ../../sda4<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 7280201c-fc5d-40f2-a9b2-466611d3d49e -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 98a81274-10f7-40db-872a-03df048df366 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 d0d0d110-0a71-4ed6-936a-304969ea36af -> ../../sda1<br />
</nowiki><br />
}}<br />
<br />
===Static device names with Udev===<br />
<br />
See [[Udev#Setting static device names]].<br />
<br />
==Using persistent naming==<br />
<br />
There are various applications that can be configured using persistent naming. Following are some examples of how to configure them.<br />
<br />
=== fstab ===<br />
<br />
See the main article: [[fstab#UUIDs]]<br />
<br />
===Boot managers===<br />
<br />
To use persistent names in your boot manager, the following prerequisites must be met:<br />
<br />
* You are using a [[Mkinitcpio#Configuration|mkinitcpio]] initial RAM disk image<br />
* You have udev enabled in {{ic|/etc/mkinitcpio.conf}}<br />
<br />
In the above example, {{ic|/dev/sda1}} is the root partition. In the [[GRUB]] {{ic|grub.cfg}} file, the ''linux'' line looks like this:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/sda1 rw quiet<br />
<br />
Depending on which naming scheme you would prefer, change it to one of the following:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/root_myhost rw quiet<br />
<br />
or:<br />
<br />
linux /boot/vmlinuz-linux root=UUID=2d781b26-0285-421a-b9d0-d4a0d3b55680 rw quiet<br />
<br />
If you are using [[LILO]], then do not try this with the {{ic|1=root=...}} configuration option; it will not work. Use {{ic|1=append="root=..."}} or {{ic|1=addappend="root=..."}} instead. Read the LILO man page for more information on {{ic|append}} and {{ic|addappend}}.<br />
<br />
There is an alternative way to use the label embedded in the filesystem. For example if (as above) the filesystem in {{ic|/dev/sda1}} is labeled {{ic|root_myhost}}, you would give this line to GRUB:<br />
<br />
linux /boot/vmlinuz-linux root=LABEL=root_myhost rw quiet</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=373600Persistent block device naming2015-05-13T23:31:31Z<p>DPiergies: /* by-label */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:File systems]]<br />
[[Category:Hardware detection and troubleshooting]]<br />
[[es:Persistent block device naming]]<br />
[[it:Persistent block device naming]]<br />
[[zh-cn:Persistent block device naming]]<br />
{{Related articles start}}<br />
{{Related|fstab}}<br />
{{Related|udev}}<br />
{{Related|LVM}}<br />
{{Related articles end}}<br />
This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like {{ic|/dev/'''sda'''}} and {{ic|/dev/'''sdb'''}} switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.<br />
{{Note|If you are using [[LVM|LVM2]], this article is not relevant as LVM takes care of this automatically.}}<br />
<br />
==Persistent naming methods==<br />
<br />
There are four different schemes for persistent naming: [[#by-label|by-label]], [[#by-uuid|by-uuid]], [[#by-id and by-path|by-id and by-path]]. For those using disks with [[GUID Partition Table|GUID Partition Table (GPT)]], two additional schemes can be used [[#by-partlabel|by-partlabel]] and [[#by-partuuid|by-partuuid]]. You can also use [[#Static device names with Udev|static device names by using Udev]].<br />
<br />
The following sections describes what the different persistent naming methods are and how they are used. <br />
<br />
The {{ic|lsblk -f}} command can be used for viewing graphically the first persistent schemes:<br />
<br />
{{hc|$ lsblk -f|<nowiki><br />
NAME FSTYPE LABEL UUID MOUNTPOINT<br />
sda <br />
├─sda1 vfat CBB6-24F2 /boot<br />
├─sda2 ext4 SYSTEM 0a3407de-014b-458b-b5c1-848e92a327a3 /<br />
├─sda3 ext4 DATA b411dc99-f0a0-4c87-9e05-184977be8539 /home<br />
└─sda4 swap f9fe0b69-a280-415d-a03a-a32752370dee [SWAP]<br />
</nowiki>}}<br />
<br />
For those using [[GUID Partition Table|GPT]], use the {{ic|blkid}} command instead. The latter is more convenient for scripts, but more difficult to read.<br />
<br />
{{hc|$ blkid|<nowiki><br />
/dev/sda1: UUID="CBB6-24F2" TYPE="vfat" PARTLABEL="EFI SYSTEM PARTITION" PARTUUID="d0d0d110-0a71-4ed6-936a-304969ea36af" <br />
/dev/sda2: LABEL="SYSTEM" UUID="0a3407de-014b-458b-b5c1-848e92a327a3" TYPE="ext4" PARTLABEL="GNU/LINUX" PARTUUID="98a81274-10f7-40db-872a-03df048df366" <br />
/dev/sda3: LABEL="DATA" UUID="b411dc99-f0a0-4c87-9e05-184977be8539" TYPE="ext4" PARTLABEL="HOME" PARTUUID="7280201c-fc5d-40f2-a9b2-466611d3d49e" <br />
/dev/sda4: UUID="f9fe0b69-a280-415d-a03a-a32752370dee" TYPE="swap" PARTLABEL="SWAP" PARTUUID="039b6c1c-7553-4455-9537-1befbc9fbc5b"<br />
</nowiki><br />
}}<br />
<br />
===by-label===<br />
{{Accuracy|Elements provided in the [[Talk:Persistent_block_device_naming|Talk page]] suggest that /dev/disk/by-label and /dev/disk/by-partlabel may not be suitable for persistent naming in certain configurations, particularly if using [[btrfs]] or [[ZFS]]}}<br />
Almost every filesystem type can have a label. All your partitions that have one are listed in the {{ic|/dev/disk/by-label}} directory. This directory is created and destroyed dynamically, depending on whether you have partitions with labels attached.<br />
<br />
{{hc|$ ls -l /dev/disk/by-label|<nowiki> <br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 DATA -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 SYSTEM -> ../../sda2<br />
</nowiki>}}<br />
<br />
The labels of your filesystems can be changed. Following are some methods for changing labels on common filesystems:<br />
<br />
; swap : {{ic|swaplabel -L <label> /dev/XXX}} using {{pkg|util-linux}}<br />
; ext2/3/4 : {{ic|e2label /dev/XXX <label>}} using {{pkg|e2fsprogs}}<br />
; btrfs : {{ic|btrfs filesystem label /dev/XXX <label>}} using {{pkg|btrfs-progs}}<br />
; reiserfs : {{ic|reiserfstune -l <label> /dev/XXX}} using {{pkg|reiserfsprogs}}<br />
; jfs : {{ic|jfs_tune -L <label> /dev/XXX}} using {{pkg|jfsutils}}<br />
; xfs : {{ic|xfs_admin -L <label> /dev/XXX}} using {{pkg|xfsprogs}}<br />
; fat/vfat : {{ic|dosfslabel /dev/XXX <label>}} using {{pkg|dosfstools}}<br />
; fat/vfat : {{ic|mlabel -i /dev/XXX ::<label>}} using {{pkg|mtools}}<br />
; ntfs : {{ic|ntfslabel /dev/XXX <label>}} using {{pkg|ntfs-3g}}<br />
<br />
{{Note|<br />
* Changing the filesystem label of the root partition has to be done from a "live" GNU/Linux distribution because the partition needs to be unmounted first.<br />
* Labels have to be unambiguous to prevent any possible conflicts;<br />
* Labels can be up to 16 characters long.}}<br />
<br />
===by-uuid===<br />
<br />
[[wikipedia:UUID|UUID]] is a mechanism to give each filesystem a unique identifier. These identifiers are generated by filesystem utilities (e.g. {{ic|mkfs.*}}) when the partition gets formatted and are designed so that collisions are unlikely. All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID. FAT and NTFS filesystems (''fat'' and ''windows'' labels above) do not support UUID, but are still listed in {{ic|/dev/disk/by-uuid}} with a shorter UID (unique identifier):<br />
<br />
{{hc|$ ls -l /dev/disk/by-uuid/|<br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 0a3407de-014b-458b-b5c1-848e92a327a3 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 b411dc99-f0a0-4c87-9e05-184977be8539 -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 CBB6-24F2 -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 f9fe0b69-a280-415d-a03a-a32752370dee -> ../../sda4<br />
}}<br />
<br />
The advantage of using the UUID method is that it is much less likely that name collisions occur than with labels. Further, it is generated automatically on creation of the filesystem. It will, for example, stay unique even if the device is plugged into another system (which may perhaps have a device with the same label). <br />
<br />
The disadvantage is that UUIDs make long code lines hard to read and break formatting in many configuration files (e.g. fstab or crypttab). Also every time a partition is resized or reformatted a new UUID is generated and configs have to get adjusted (manually).<br />
<br />
{{Tip|In case your swap partition does not have an UUID assigned, you will need to reset the swap partition using [[Swap#Swap partition|mkswap]] utility.}}<br />
<br />
===by-id and by-path===<br />
{{Accuracy|Elements provided in the [[Talk:Persistent_block_device_naming|Talk page]] (since 2011) seems to clearly indicate that {{ic|by-id}} and {{ic|by-path}} are valid ways to state persistent device names. Were they not, this section should be marked for deletion so as to not bring up confusion in this page dedicated to ''persistent device naming''.|section=by-path and by-id unsuitable?}}<br />
{{ic|by-id}} creates a unique name depending on the hardware serial number, {{ic|by-path}} depending on the shortest physical path (according to sysfs). Both contain strings to indicate which subsystem they belong to (i.e. {{ic|-ide-}} for {{ic|by-path}}, and {{ic|-ata-}} for {{ic|by-id}}) and thus are not suitable for solving the problems mentioned in the beginning of this article. They will not be discussed any further here.<br />
<br />
===by-partlabel===<br />
{{Note|This method only concerns disks with [[GUID Partition Table|GUID Partition Table (GPT)]].}}<br />
<br />
Partition labels can be defined in the header of the partition entry on GPT disks.<br />
<br />
See also [[Wikipedia:GUID_Partition_Table#Partition_entries]].<br />
<br />
This method is very similar to the [[#by-label|filesystem labels]], excepted that the dynamic directory is {{ic|/dev/disk/by-partlabel}}.<br />
<br />
{{hc|ls -l /dev/disk/by-partlabel/|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 EFI\x20SYSTEM\x20PARTITION -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 GNU\x2fLINUX -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 HOME -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 SWAP -> ../../sda4<br />
</nowiki>}}<br />
<br />
{{Note|<br />
* GPT partition labels have also to be different to avoid conflicts. To change your partition label, you can use {{ic|gdisk}} or the ncurse-based version {{ic|cgdisk}}. Both are available from the {{Pkg|gptfdisk}} package. See [[Partitioning#Partitioning_tools]].<br />
* According to the specification, GPT partition labels can be up to 72 characters long.}}<br />
<br />
===by-partuuid===<br />
{{Note|This method only concerns disks with [[GUID Partition Table|GUID Partition Table (GPT)]].}}<br />
<br />
Like [[#by-partlabel|GPT partition labels]], GPT partition UUID are defined in the partition entry on GPT disks. <br />
<br />
See also [[Wikipedia:GUID_Partition_Table#Partition_entries]].<br />
<br />
The dynamic directory is similar to other methods and, like [[#by-uuid|UUID filesystems]], using UUIDs is prefered over labels.<br />
<br />
{{hc|ls -l /dev/disk/by-partuuid/|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 039b6c1c-7553-4455-9537-1befbc9fbc5b -> ../../sda4<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 7280201c-fc5d-40f2-a9b2-466611d3d49e -> ../../sda3<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 98a81274-10f7-40db-872a-03df048df366 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 May 27 23:31 d0d0d110-0a71-4ed6-936a-304969ea36af -> ../../sda1<br />
</nowiki><br />
}}<br />
<br />
===Static device names with Udev===<br />
<br />
See [[Udev#Setting static device names]].<br />
<br />
==Using persistent naming==<br />
<br />
There are various applications that can be configured using persistent naming. Following are some examples of how to configure them.<br />
<br />
=== fstab ===<br />
<br />
See the main article: [[fstab#UUIDs]]<br />
<br />
===Boot managers===<br />
<br />
To use persistent names in your boot manager, the following prerequisites must be met:<br />
<br />
* You are using a [[Mkinitcpio#Configuration|mkinitcpio]] initial RAM disk image<br />
* You have udev enabled in {{ic|/etc/mkinitcpio.conf}}<br />
<br />
In the above example, {{ic|/dev/sda1}} is the root partition. In the [[GRUB]] {{ic|grub.cfg}} file, the ''linux'' line looks like this:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/sda1 rw quiet<br />
<br />
Depending on which naming scheme you would prefer, change it to one of the following:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/root_myhost rw quiet<br />
<br />
or:<br />
<br />
linux /boot/vmlinuz-linux root=UUID=2d781b26-0285-421a-b9d0-d4a0d3b55680 rw quiet<br />
<br />
If you are using [[LILO]], then do not try this with the {{ic|1=root=...}} configuration option; it will not work. Use {{ic|1=append="root=..."}} or {{ic|1=addappend="root=..."}} instead. Read the LILO man page for more information on {{ic|append}} and {{ic|addappend}}.<br />
<br />
There is an alternative way to use the label embedded in the filesystem. For example if (as above) the filesystem in {{ic|/dev/sda1}} is labeled {{ic|root_myhost}}, you would give this line to GRUB:<br />
<br />
linux /boot/vmlinuz-linux root=LABEL=root_myhost rw quiet</div>DPiergieshttps://wiki.archlinux.org/index.php?title=Talk:Persistent_block_device_naming&diff=373599Talk:Persistent block device naming2015-05-13T23:25:53Z<p>DPiergies: /* by-path and by-id unsuitable? */</p>
<hr />
<div>== by-path and by-id unsuitable? ==<br />
<br />
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')"<br />
<br />
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.<br />
<br />
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.)<br />
<br />
[[User:Thetrivialstuff|Thetrivialstuff]] 01:04, 13 August 2011 (EDT)<br />
<br />
: I am also confused by that statement in the article with respect to "by-id". E.g. elsewhere I see:<br />
: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/persistent_naming.html<br />
:: 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.'''<br />
:: 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.<br />
:: For example, a device with a page 0x83 identifier would have:<br />
<br />
:: scsi-3600508b400105e210000900000490000 -> ../../sda<br />
<br />
:: Or, a device with a page 0x80 identifier would have:<br />
<br />
:: scsi-SSEAGATE_ST373453LW_3HW1RHM6 -> ../../sda<br />
<br />
:: 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. '''<br />
: Am I missing something?<br />
: [[User:Goulo|Goulo]] 04:42, 11 January 2012 (EST)<br />
:: 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 --[[User:Kit|Kit]] ([[User talk:Kit|talk]]) 17:49, 25 October 2012 (UTC)<br />
<br />
It seems to me that /dev/disk/by-id is a perfectly suitable 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 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.<br />
[[User:DPiergies|DPiergies]] ([[User talk:DPiergies|talk]]) 23:25, 13 May 2015 (UTC)</div>DPiergies