Question

我将EBS卷附加到我的EC2实例，将其转换为EXT3文件系统，并成功安装它。但是，最初我被抛弃了主要是因为AWS控制台说我的EBS设备ID是什么。

根据AWS控制台：

i-xxxxxxx :/dev/sdf (attached)

我认为这意味着我附加的EBS设备ID是/ dev / sdf。因此，当我尝试使用此设备ID将设备转换为文件系统时，我收到以下错误消息。

ubuntu@ip-xx-xx-xx-xx:~$ mkfs -t ext3 /dev/sdf
mke2fs 1.42 (29-Nov-2011)
Could not stat /dev/sdf --- No such file or directory
The device apparently does not exist; did you specify it correctly?

然后经过一段时间的研究后，我找到了this文章，然后通过运行 cat /proc/partitions 发现我的真实设备ID是/ dev / xvdf而不是/ dev / sdf。

我的问题是为什么AWS控制台在实际上是/ dev / xvdf时会说它是/ dev / sdf？我认为必须有一些合乎逻辑的解释。

Answer 1

通过AWS Management Console附加卷时，AWS会提供以下消息/警告：

注意：较新的Linux内核可能会将您的设备重命名为/ dev / xvdf / dev / xvdp内部，即使在这里输入设备名称（和详细信息中显示的是/ dev / sdf到/ dev / sdp。

我没有这个信息的任何上游来源，但是Jay Rum对（不再相关的）临时问题EBS Disks starting as device /dev/xvde, but mapped as /dev/sda的回答将此功能归因于xen-blkfront驱动程序：

“xen-blkfront”驱动程序，它允许虚拟机（即 EC2实例）传统上访问底层块设备映射sda，sdb ...到xvda，xvdb ...，[...]

最后，cyberx86对How do I access the attached volume in Amazon EC2的回答提供了有关此设备命名不匹配以及如何处理它的详细说明，即识别当前可用的设备等。

_{注意：这个问题已在12月24日得到解答，但是在6月01日由社区版主删除了6个upvotes的答案（即自动转发）处理）出于非透明的原因（显然是因为用户被移除） - 无论如何，我从我的角度添加了原始内容的略微变化。}

EC2：EBS设备ID混淆（/ dev / sdf vs. / dev / xvdf）

1 个答案: