42

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/sdf ではなく /dev/xvdf であることがわかりました。

私の質問は、実際には /dev/xvdf であるのに、AWS コンソールが /dev/sdf であると言っているのはなぜですか? これには何らかの論理的な説明が必要だと思います。

4

1 に答える 1

38

AWSマネジメント コンソール経由でボリュームをアタッチすると、AWS は次のメッセージ/警告を表示します。

注: 新しい Linux カーネルでは、デバイスの名前が内部的に /dev/xvdp を介して /dev/xvdf に変更される場合があります。これは、ここで入力された (および詳細に表示された) デバイス名が /dev/sdf から /dev/sdp であってもです。

この情報に関するアップストリームの情報源は手元にありませんが、ジェイ・ラムの (関連性がなくなった) 一時的な問題EBS Disks starting as device /dev/xvde, but maps as /dev/sdaに対する Jay Rum の回答は、この機能をxen-blkfrontドライバーに関連付けています:

仮想マシン (つまり、EC2 インスタンス) が基礎となるブロックデバイスにアクセスできるようにする「xen-blkfront」ドライバーは、伝統的に sda、sdb... を xvda、xvdb...、[...] にマッピングします。

最後に、 Amazon EC2 の接続されたボリュームにアクセスする方法に対する Cyber​​x86 の回答では、このデバイスの名前の不一致とその対処方法 (つまり、現在利用可能なデバイスの特定など) の詳細な説明と図解が提供されています。

注: この質問は 2012 年 8 月 24 日に既に回答されていますが、6 票の回答は 2013 年 5 月 1 日にコミュニティ モデレーター(自動化プロセス) によって非透明な理由 (明らかにユーザーが削除されたため) で削除されました) - とにかく、私の観点から、元のコンテンツのわずかなバリエーションを追加し直しました。

于 2013-05-01T20:52:05.653 に答える