我将一个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?
经过一点研究，我找到了这篇文章，然后通过运行 cat /proc/partitions 发现我真正的设备id是/dev/xvdf，而不是/dev/sdf。
我的问题是，为什么AWS控制台说它是/dev/sdf，而实际上它是/dev/xvdf？我认为对此必须有某种合乎逻辑的解释。
AWS在通过AWS管理控制台连接卷时提供以下消息/警告：
注意：较新的linux内核可能会通过将您的设备重命名为/dev/xvdf/dev/xvdp内部，即使在此处输入设备名称（以及显示在详细信息中）是/dev/sdf到/dev/sdp。
我手头没有任何上游信息来源，但Jay Rum对（不再相关的）临时问题的回答EBS磁盘启动为设备/dev/xvde，但映射为/dev/sda，将此功能归因于xen-blkfront驱动程序：
"xen-blkfront"驱动程序，它允许虚拟机（即EC2实例）来访问底层块设备映射了sda、sdb。。。到xvda、xvdb。。。，[…]
最后，cyberx86对我如何访问亚马逊EC2中的连接卷的回答提供了对这种设备命名不匹配以及如何处理的详细说明，即识别当前可用的设备等。
注意：这个问题已经在12年8月24日得到了回答，但在2013年5月1日，社区主持人（即相应的自动化过程）出于不透明的原因（显然是因为用户被删除了）删除了6张赞成票的回答-无论如何，从我的角度来看，我添加了原始内容的微小变化