Linux 如何将 /dev/sda 与 /dev/sdb 交换？

How do you swap /dev/sda with /dev/sdb?

提问by Florian Mertens

Boy, this is such. a. trivial. question, and yet nobody seems to be able to answer it correctly.

男孩，是这样的。一种。琐碎的。问题，但似乎没有人能够正确回答。

How do you swap /dev/sda with /dev/sdb ?

如何将 /dev/sda 与 /dev/sdb 交换？

Someone can suggest to use permanent labelling (eg. /dev/disk/by-* ), but despite the best intentions, this does NOTanswer the question. Yes, permanent labellings works where you can use them, but if a program is hardcoded to use eg. /dev/sda, this question persists.

有人可以建议使用永久标签（例如 /dev/disk/by-* ），但尽管有最好的意图，但这并不能回答问题。是的，永久标签可以在您可以使用它们的地方使用，但是如果程序被硬编码使用，例如。/dev/sda，这个问题仍然存在。

To illustrate the problem further from what I found on the internet: http://ubuntuforums.org/showthread.php?t=1569238&page=2(Reminds me of 'Schadenfreude')

为了进一步说明我在互联网上发现的问题： http://ubuntuforums.org/showthread.php?t=1569238&page=2（让我想起“幸灾乐祸”）

This chap seems to have found the solution, just didn't share it (boo!): http://ubuntuforums.org/showthread.php?t=944515

这个家伙似乎找到了解决方案，只是没有分享它（嘘！）：http: //ubuntuforums.org/showthread.php?t=944515

And tbh, I have a potential similar hazard. I use CloneZilla, and if a program asks: Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?, guess how nervous I get knowing that linux seems to randomly assign disk orders. I haven't overwritten my data with my own backup yet, but this is just waiting to happen.

tbh，我有潜在的类似危险。我使用 CloneZilla，如果程序询问：Would you like to backup /dev/sda to /dev/sdb or /dev/sdb to /dev/sda ?，猜猜我知道 linux 似乎随机分配磁盘顺序是多么紧张。我还没有用我自己的备份覆盖我的数据，但这只是等待发生。

What within Linux assigns /dev/sd* to disks, and how do you influence this process? Has this got something to do with udev (/etc/udev/, udevadm)? My OS is CentOS, but I need to know this also for Ubuntu and CloneZilla (http://clonezilla.org), and this problem occurs on all systems, so my guess is that this problem is not related to the distribution, but rather to the kernel, kernel modules, or something very close to the kernel. Please help!

在 Linux 中，什么将 /dev/sd* 分配给磁盘，您如何影响这个过程？这与 udev (/etc/udev/, udevadm) 有关系吗？我的操作系统是 CentOS，但我也需要知道 Ubuntu 和 CloneZilla ( http://clonezilla.org) 的这一点，并且这个问题在所有系统上都会发生，所以我猜这个问题与发行版无关，而是与发行版有关到内核​​、内核模块或非常接近内核的东西。请帮忙！

------------------ EDIT: 25 August 2013After advising the link that ypnos gave, I read it all, tried out one command, and the kernel just 'vommitted' udev rules all over my screen. Then prompted for root password to allow maintenance, or exit for restart. This is evidence that this stuff is indeed not for the Novice person.

------------------ 编辑：2013 年 8 月 25 日在建议 ypnos 提供的链接后，我阅读了所有内容，尝试了一个命令，内核只是“呕吐”了 udev 规则我的屏幕上到处都是。然后提示输入 root 密码以允许维护，或退出重新启动。这证明这东西确实不适合新手。

I also looked it up a bit further. I don't understand how or when the linux kernel loads, but several messages on the internet indicate that the BIOS (!! believe it or not) is passing the list of booteable disks down to grub, which then uses the device.map file to assign which devices to which grub (hd*,). Note that /dev/sdhave already been defined at this stage, as you can use permanent dev symlinks. These device maps seem to somehow pass on to the actual root file system. So is this a bootloader thing now?

我也仔细看了看。我不明白 linux 内核是如何或何时加载的，但互联网上的几条消息表明 BIOS（信不信由你）正在将可引导磁盘列表传递给 grub，然后 grub 使用 device.map 文件将哪些设备分配给哪些 grub (hd*, )。请注意，/dev/sd已在此阶段定义，因为您可以使用永久开发符号链接。这些设备映射似乎以某种方式传递到实际的根文件系统。那么这是一个引导加载程序吗？

Going back to the udev as a potential solution, I found a bugreport on google http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578826, that resulted in a resolution where it was DISadviced to change the udev NAME (that ultimately will become /dev/sd* as we know it).

回到 udev 作为一个潜在的解决方案，我在 google http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578826上发现了一个错误报告，这导致了一个解决方案，它不建议更改udev NAME（最终将成为我们所知的 /dev/sd*）。

For the suggested udev MAN pages:

对于建议的 udev MAN 页面：

| The following keys can get values assigned:
| 
| NAME
|  The name of the node to be created, or the name the network
|  interface should be renamed to.
   NOTE: changing the kernel-provided name of device nodes
   (except for network devices) is not supported and can result
   in unexpected behavior.
   Today, the kernel defines the device nodes names, and udev
   is expected to only manage the node's permissions and
   additional symlinks.

...But I went out to do it anyway in a slightly altered way.

......但无论如何我还是以稍微改变的方式出去做这件事。

# vi /etc/udev/rules.d/00-corrections.rules

KERNEL=="sd?", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda"
KERNEL=="sd??", ATTRS{model}=="SAMSUNG SP0411N", NAME="sda%n"
KERNEL=="sda", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb"
KERNEL=="sda?", ATTRS{model}!="SAMSUNG SP0411N", NAME="sdb%n"

Essentially, what it does is "If model is samsung, assign it NAME sda*. If model is not Samsung, but has been assigned sda*, assign it NAME sdb*." This rule was placed before all other rules as much as possible. Note that I am not sure about this, because there seem to be some 'invisible' rule files also, AND although you have renamed the devices, the kernel somewhere in 'kernel-loaded-memory', still might have the references wrong. This might be evident when you look at the /var/log/boot.log file, where in my case, the beginning it says:

本质上，它的作用是“如果型号是三星，则将其分配给 NAME sda*。如果型号不是三星，但已分配给 sda*，则将其分配给 NAME sdb*。” 这条规则尽可能放在所有其他规则之前。请注意，我对此不确定，因为似乎还有一些“不可见”规则文件，并且尽管您已重命名设备，但“内核加载内存”中某处的内核仍然可能引用错误。当您查看 /var/log/boot.log 文件时，这可能很明显，在我的情况下，它的开头说：

%G      Welcome to [0;36mCentOS[0;39m 
Starting udev: %G[60G[[0;32m  OK  [0;39m]Setting hostname UncleFloServer:  [60G[[0;32m  OK  [0;39m]ERROR: asr: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998795264
ERROR: ddf1: seeking device "/dev/sda" to 5999998664192
ERROR: hpt45x: seeking device "/dev/sda" to 5999998790144
ERROR: isw: seeking device "/dev/sda" to 5999998794752
ERROR: jmicron: seeking device "/dev/sda" to 5999998795264
ERROR: lsi: seeking device "/dev/sda" to 5999998795264
ERROR: nvidia: seeking device "/dev/sda" to 5999998794752
ERROR: pdc: seeking device "/dev/sda" to 137438913024
ERROR: pdc: seeking device "/dev/sda" to 137438920192
ERROR: pdc: seeking device "/dev/sda" to 137438927360
ERROR: pdc: seeking device "/dev/sda" to 137438934528
ERROR: sil: seeking device "/dev/sda" to 5999998795264
ERROR: via: seeking device "/dev/sda" to 5999998795264
Setting up Logical Volume Management:   No volume groups found
[60G[[0;32m  OK  [0;39m]Checking filesystems
_CentOS-6.4-x86_: clean, 85517/655360 files, 662649/2621440 blocks
/dev/sda1: clean, 56/65536 files, 33367/262144 blocks
[60G[[0;32m  OK  [0;39m]Remounting root filesystem in read-write mode:  [60G[[0;32m  OK  [0;39m]Mounting local filesystems:  [60G[[0;32m  OK  [0;39m]Enabling local filesystem quotas:  [60G[[0;32m  OK  [0;39m]Enabling /etc/fstab swaps:  [60G[[0;32m  OK  [0;39m]

Here, my Samsung device is 40GB (that I would like as /dev/sda), and my big Areca Raid is 6TB (that I would like as /dev/sdb).

在这里，我的三星设备是 40GB（我希望作为 /dev/sda），而我的大型 Areca Raid 是 6TB（我希望作为 /dev/sdb）。

Some remaining questions remain

剩下的一些问题仍然存在

1. What do the errors mean?

2. Are these errors the cause of the kernel, or the cause of a rule file still running before my 00-corrections.rules from udev?

3. Do these errors indicate something data- threatening? The Areca partition mounted no problems on one of my folders in fstab.

4. Is there a better, earlier device-assignment method?

1. 错误是什么意思？

2. 这些错误是内核的原因，还是在 udev 的 00-corrections.rules 之前仍然运行的规则文件的原因？

3. 这些错误是否表明存在数据威胁？Areca 分区在 fstab 中的一个文件夹上安装没有问题。

4. 有没有更好、更早的设备分配方法？

采纳答案by ypnos

These days, the Linux kernel dynamically populates /dev/ according to UDEV rules.

现在，Linux 内核根据 UDEV 规则动态填充 /dev/。

Let me first explain how device files work. Each device file, typically a block device file, has a major and a minor number. These numbers actually describe what device the file points to. The name does not play any role in this. Let's have a look at our specific case of disks:

让我先解释一下设备文件是如何工作的。每个设备文件（通常是块设备文件）都有一个主设备号和一个次设备号。这些数字实际上描述了文件指向的设备。这个名字在这方面没有任何作用。让我们来看看我们磁盘的具体情况：

# ls -l sd*
brw-rw---- 1 root disk 8, 0 Aug 22 15:45 sda
brw-rw---- 1 root disk 8, 1 Aug 22 15:45 sda1
brw-rw---- 1 root disk 8, 2 Aug 22 15:45 sda2
brw-rw---- 1 root disk 8, 3 Aug 22 15:45 sda3
brw-rw---- 1 root disk 8, 5 Aug 22 15:45 sda5
brw-rw---- 1 root disk 8, 6 Aug 22 15:45 sda6

Here you see that my first disk has various partitions and that I booted on Aug 22, at 3pm, which is when the kernel created the files according to rules. You can also see that the major number is 8 and the minor numbers are used to access partitions (0 pointing to the whole disk). The 'b' in the beginning of each line tells that each of these is a special "block device" file.

在这里你可以看到我的第一个磁盘有不同的分区，并且我在 8 月 22 日下午 3 点启动，这是内核根据规则创建文件的时间。您还可以看到主编号为 8，次编号用于访问分区（0 指向整个磁盘）。每行开头的 'b' 表示这些文件中的每一个都是一个特殊的“块设备”文件。

As I said, the kernel creates the files dynamically "these days". It was not always like that and it is not like that on other Unix systems. There, files would be created statically, and, the user would create or manipulate these files.

正如我所说，内核“这些天”动态创建文件。并非总是如此，在其他 Unix 系统上也并非如此。在那里，文件将被静态创建，并且用户将创建或操作这些文件。

It is perfectly possible to create your own device files, with your own name, and major/minor numbers. See mknod(man mknod) for that. However, after you boot again, your custom files will disappear.

完全可以使用您自己的名称和主要/次要编号创建自己的设备文件。请参阅mknod( man mknod)。但是，再次启动后，您的自定义文件将消失。

The second possibility is to change UDEV rules. The rules will be processed during system boot, and guarantee you a permanently consistent behavior. A good guide on these rules ca be found here: http://www.reactivated.net/writing_udev_rules.html

第二种可能是改变UDEV规则。这些规则将在系统启动期间进行处理，并保证您的行为永久一致。可以在此处找到有关这些规则的良好指南：http: //www.reactivated.net/writing_udev_rules.html

You will see that it is possible to define a rule that creates "sda*" given specific hardware info that matches your device. You will need to replace the original rules that would create sda with yours. How this works depends on your distribution.

您将看到可以定义一个规则，在给定与您的设备匹配的特定硬件信息的情况下创建“sda*”。您将需要用您的规则替换将创建 sda 的原始规则。这如何工作取决于您的发行版。

As I think this is a dangerous business for the novice, I will not explain you specific steps; the document I linked above will give you all information you need, and you should indeed read it all.

由于我认为这对新手来说这是一项危险的业务，因此我不会向您解释具体步骤；我上面链接的文档将为您提供所需的所有信息，您确实应该阅读所有内容。

回答by James

As far as I know it's not possible. The system will pick SATA port 1 as SDA and so forth. You can however use smartctl to identify the serial number of SDA/B or flash the drive LEDs where possible.

据我所知这是不可能的。系统将选择 SATA 端口 1 作为 SDA，依此类推。但是，您可以使用 smartctl 来识别 SDA/B 的序列号或在可能的情况下闪烁驱动器 LED。

回答by Maurice M

Why don't you use UUID instead of relying on dynamic assignment ? SD? is always dynamic, while UUID is fixed value and don't change, even if you change, distro or if you install your hard drive in other Linux machine the UUID will be the same.

为什么不使用 UUID 而不是依赖动态分配？标清？始终是动态的，而 UUID 是固定值并且不会更改，即使您更改发行版或将硬盘驱动器安装在其他 Linux 机器上，UUID 也将相同。

sudo blkid will show you the UUID then you can use it on you fstab to mount the partitions wherever you want.

sudo blkid 将向您显示 UUID，然后您可以在 fstab 上使用它来将分区挂载到您想要的任何位置。