Linux按照什么算法分配硬盘盘符？

Question 1

驱动器名称（在典型的 Linux 系统上）由内核决定（因为必须首先在内核中检测到设备），并且稍后可以由 udev 修改。如何它决定哪个硬件映射到哪个块特殊文件是一个实现细节，这将取决于您的 udev 配置、内核配置、模块设置和许多其他东西（包括运气）。

即使使用相同的硬件和配置，设备到驱动器号的映射也不能保证始终相同（有些系统特别容易由于竞争条件而交换设备名称，例如并行模块加载中的系统）。

要回答您没有提出的问题，请勿将其用作/dev/sd*任何内容的标识符，除非您事先确定要安装的设备（例如，您在使用fdisk和/或检查后手动安装blkid）。相反，使用文件系统标签、文件系统 UUID 或磁盘 ID 来确保您通过其属性（而不是其检测顺序）指向正确的设备、分区或文件系统。您可以在中找到磁盘 ID /dev/disk/by-id，这是一个方便的挂载位置，并保证您始终使用同一磁盘。

/dev/sda1例如，要查找可用于当前分区的磁盘 ID ，您可以使用find：

$ find -L /dev/disk/by-id -samefile /dev/sda1
/dev/disk/by-id/wwn-0x5000cca22dd9fc29-part1
/dev/disk/by-id/ata-HGST_HUS724020ALA640_PN1181P6HV51ZW-part1

Answer

驱动器名称（在典型的 Linux 系统上）由内核决定（因为必须首先在内核中检测到设备），并且稍后可以由 udev 修改。如何它决定哪个硬件映射到哪个块特殊文件是一个实现细节，这将取决于您的 udev 配置、内核配置、模块设置和许多其他东西（包括运气）。

即使使用相同的硬件和配置，设备到驱动器号的映射也不能保证始终相同（有些系统特别容易由于竞争条件而交换设备名称，例如并行模块加载中的系统）。

要回答您没有提出的问题，请勿将其用作/dev/sd*任何内容的标识符，除非您事先确定要安装的设备（例如，您在使用fdisk和/或检查后手动安装blkid）。相反，使用文件系统标签、文件系统 UUID 或磁盘 ID 来确保您通过其属性（而不是其检测顺序）指向正确的设备、分区或文件系统。您可以在中找到磁盘 ID /dev/disk/by-id，这是一个方便的挂载位置，并保证您始终使用同一磁盘。

/dev/sda1例如，要查找可用于当前分区的磁盘 ID ，您可以使用find：

$ find -L /dev/disk/by-id -samefile /dev/sda1
/dev/disk/by-id/wwn-0x5000cca22dd9fc29-part1
/dev/disk/by-id/ata-HGST_HUS724020ALA640_PN1181P6HV51ZW-part1

Question 2

相关问题（来自自动侧边栏）：如何防止引导之间 /sda /sdb 发生变化？

它保证按照内核“探测”（或“绑定”）的顺序分配它们。

Greg KH 主张不要依赖该命令。他喜欢举一个（真实的！）设计得很丑陋的主板的例子，它会在后续启动之间重新安排 PCI 顺序。听起来上面的问题就是关于这样一个例子。

可加载模块由用户空间加载。udev使用多个进程并行化，并且不保证以任何特定顺序加载模块。像这样的并行初始化可以带来真正的性能优势，因为模块初始化函数可以并行运行，并且这些函数可能包括等待硬件的长时间延迟。

目前，可以假设内核默认是要探测内置驱动程序同步，因此按确定的顺序。

从 v4.2 开始，Linux 内核现在支持异步探测

（显然这个功能是由 Google Chrome OS 使用的）。

https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

https://kernelnewbies.org/Linux_4.2#Core

基于历史消息你可能也认为人们对这些努力持怀疑/疲劳态度，尤其是来自 Linus。基于上述情况，似乎任何加强的审查和/或激烈的喊叫信息都没有妨碍合并这一选项。

在内核范围内启用它是另一回事，因为“由于驱动程序错误或不是最佳的驱动程序组织，[某些]驱动程序不能很好地与异步探测一起工作”。也许 Linus 并没有在合并的提交消息中爆发（？），该消息说“最终目标是默认情况下使探测异步”，但这只是一种观点，并且它并没有告诉我们自那以来它的进展情况如何v4.2。

Answer

相关问题（来自自动侧边栏）：如何防止引导之间 /sda /sdb 发生变化？

它保证按照内核“探测”（或“绑定”）的顺序分配它们。

Greg KH 主张不要依赖该命令。他喜欢举一个（真实的！）设计得很丑陋的主板的例子，它会在后续启动之间重新安排 PCI 顺序。听起来上面的问题就是关于这样一个例子。

可加载模块由用户空间加载。udev使用多个进程并行化，并且不保证以任何特定顺序加载模块。像这样的并行初始化可以带来真正的性能优势，因为模块初始化函数可以并行运行，并且这些函数可能包括等待硬件的长时间延迟。

目前，可以假设内核默认是要探测内置驱动程序同步，因此按确定的顺序。

从 v4.2 开始，Linux 内核现在支持异步探测

（显然这个功能是由 Google Chrome OS 使用的）。

https://www.do-not-panic.com/2015/12/linux-asynchronous-probe.html

https://kernelnewbies.org/Linux_4.2#Core

基于历史消息你可能也认为人们对这些努力持怀疑/疲劳态度，尤其是来自 Linus。基于上述情况，似乎任何加强的审查和/或激烈的喊叫信息都没有妨碍合并这一选项。

在内核范围内启用它是另一回事，因为“由于驱动程序错误或不是最佳的驱动程序组织，[某些]驱动程序不能很好地与异步探测一起工作”。也许 Linus 并没有在合并的提交消息中爆发（？），该消息说“最终目标是默认情况下使探测异步”，但这只是一种观点，并且它并没有告诉我们自那以来它的进展情况如何v4.2。

Question 3

我有一个外部 USB 驱动器，我通过标签安装它，因此它总是在 fstab 运行时安装，但是，我仍然遇到问题。有时，即使安装了设备，驱动器分配也会发生变化，并且更改后的驱动器上的文件将无法访问。

我正在运行 Ubuntu 16.04.4 LTS (Linux 4.4.0-128-generic i686)。

我在日常会话之间使用睡眠模式，并且我怀疑从睡眠模式唤醒时驱动器会被重新分配，尽管我对此并不确定。通常它分配为 /dev/sdc，我有一个 USB SD 读卡器，我将其插入，分配为 /dev/sdd。有时我无法读取或写入外部驱动器。发生这种情况时，我发现它已被重新分配到/dev/sde。一个修复方法是简单地重新启动操作系统，一切都会恢复正常，但我正在寻找一种不需要走极端的修复方法。

我发现更好的解决方法是首先关闭正在访问外部驱动器上任何分区的所有应用程序，包括外部驱动器上分区上的文件夹上的任何终端选项卡。如果我有一个应用程序对无法访问的驱动器上的文件进行了更改，则有必要将该文件保存到另一个可访问的分区，原因有两个：1）保存数据，2）破坏链接到无法访问的分区。然后我卸载分区

sudo umount /dev/sde

或外部驱动器所有分区的任何分配。然后我重新安装所有分区

sudo mount -a

执行此操作后，我发现任何应用程序现在都可以再次访问错误的分区，即使该分区仍分配为 /dev/sde 而不是预期的 /dev/sdc。由于 fstab 使用标签并将这些分区安装到文件夹，因此这种重新分配不是问题。我似乎每个月都要这样做两三次。

我想知道，即使我使用标签进行分区标识，安装是否将标签映射到设备字母分配，这就是导致此问题的原因。我不能肯定地说……只是思考。

Answer

我有一个外部 USB 驱动器，我通过标签安装它，因此它总是在 fstab 运行时安装，但是，我仍然遇到问题。有时，即使安装了设备，驱动器分配也会发生变化，并且更改后的驱动器上的文件将无法访问。

我正在运行 Ubuntu 16.04.4 LTS (Linux 4.4.0-128-generic i686)。

我在日常会话之间使用睡眠模式，并且我怀疑从睡眠模式唤醒时驱动器会被重新分配，尽管我对此并不确定。通常它分配为 /dev/sdc，我有一个 USB SD 读卡器，我将其插入，分配为 /dev/sdd。有时我无法读取或写入外部驱动器。发生这种情况时，我发现它已被重新分配到/dev/sde。一个修复方法是简单地重新启动操作系统，一切都会恢复正常，但我正在寻找一种不需要走极端的修复方法。

我发现更好的解决方法是首先关闭正在访问外部驱动器上任何分区的所有应用程序，包括外部驱动器上分区上的文件夹上的任何终端选项卡。如果我有一个应用程序对无法访问的驱动器上的文件进行了更改，则有必要将该文件保存到另一个可访问的分区，原因有两个：1）保存数据，2）破坏链接到无法访问的分区。然后我卸载分区

sudo umount /dev/sde

或外部驱动器所有分区的任何分配。然后我重新安装所有分区

sudo mount -a

执行此操作后，我发现任何应用程序现在都可以再次访问错误的分区，即使该分区仍分配为 /dev/sde 而不是预期的 /dev/sdc。由于 fstab 使用标签并将这些分区安装到文件夹，因此这种重新分配不是问题。我似乎每个月都要这样做两三次。

我想知道，即使我使用标签进行分区标识，安装是否将标签映射到设备字母分配，这就是导致此问题的原因。我不能肯定地说……只是思考。

Question 4

Linux 对于设备名称到物理硬盘的映射有何保证？

它使用哪些规则将物理硬盘驱动器映射到 /dev/ 中的文件？

我不能代表每个 Linux 发行版，但我可以代表 SUSE 是如何做到的，在 SUSE 中可以使用这些选项

挂载点

设备名称
设备ID
体积标识
设备路径
通用唯一标识符

按设备名称我会说是坏的因为它会导致 linux 检查硬件和命令其中它看到连接的驱动器就是它如何映射到 sda、sdb 等。因此，如果您的引导设备和分区被称为 sda，并且您只需切换可移动插槽（在服务器上）中的驱动器顺序或在家用计算机中的两个驱动器之间切换SATA电缆，就会造成混乱。另外，我的经验是（在具有 8、16 或 24 个驱动器托架的服务器上），驱动器插槽 0 经常会倒退，不会映射到 sda...如果您有 3 个驱动器，则插槽 2 是 sda，插槽 1 是 sdb，和插槽 0 sdc。并添加任何被映射为/dev/sda并将驱动器向下推一个字母的临时硬件，这会扰乱事情。但我想说，当设置您计划克隆的黄金映像操作系统驱动器时，这种方法很好......您不必担心新磁盘上的硬盘驱动器 ID 或 WWN 至少在一段时间内会发生变化。 ..如果是仅有的系统中的磁盘很可能始终显示为 sda。

FSTAB syntax:**
/dev/sdc2 / EXT3 acl,user_xattr 1 1
/dev/sdc1 /boot/efi VFAT
/dev/sdb1 /data XFS defaults 1 0

通过设备 ID是我经常使用的，因为它解决了基本上“按设备名称”提到的所有问题，多年来它对我来说效果很好，几乎所有问题。通过设备 ID 配置安装后，只需存在或连接驱动器即可。如果驱动器移动或新硬件被映射为某些，/dev/sd?它不会影响之前配置的任何内容。

FSTAB syntax:
/dev/disk/by-id/scsi-35000aab12345a30-part2 / EXT3 acl,user_xattr 1 1
/dev/disk/by-id/scsi-35000aab12345a30-part1 /boot/efi VFAT
/dev/disk/by-id/scsi-3600404abc123def456-part1 /data XFS defaults 1 0

通过 UUID {通用唯一标识符}我认为这也是一个很好的方法，它的工作原理很像“按设备 ID”，但是我不知道 UUID 是如何创建并使其唯一的，或者它最终是否与按设备 ID 相同？

按卷标如果您或某人已经为要安装的任何文件系统或分区或卷制作了良好的卷标签，也可以很好地工作。我确信如果两个分区具有相同的卷标（例如“boot”），则会出现问题怀疑如果 linux 不报告重复的卷标，则它将使用第一个找到的卷标。

另外，这都是基于linux Udev（以回答使用哪种算法）。我相信旧的 Init linux 和新的 Systemd linux 都是一样的，因为 Udev 是大多数 Linux 发行版中使用的软件包。和我认为主要是/etc/fstab 每行的第一个字段或列中的语法决定了将要发生的安装方法（而不是算法），在某处没有其他配置文件，我这么说是因为/etc/fstab每个行中可以有多行通过不同的挂载方法（通过名称、id、uuid 或标签）挂载不同的东西，据我所知，除了 fstab 文件中的语法之外，其他任何地方都没有改变。

Answer