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/sdfではなく/ dev/xvdfでした。
私の質問は、AWSコンソールが実際に/ dev/xvdfであるのに/ dev/sdfであると言っているのはなぜですか?これには何らかの論理的な説明が必要だと思います。
AWSは、 AWS Management Console を介してボリュームをアタッチするときに次のメッセージ/警告を提供します。
注:新しいLinuxカーネルは、ここで入力したデバイス名(および詳細に表示)が/ dev/sdfから/ dev/sdpであっても、デバイスの名前を内部で/ dev/xvdpから/ dev/xvdfに変更する場合があります。
この情報のアップストリームソースは手元にありませんが、(もはや関係のない)一時的な問題に対するジェイラムの回答 EBSディスクはデバイス/ dev/xvdeとして始まりますが、/ dev/sdaとしてマップされます この機能をxen-blkfront
運転者:
「xen-blkfront」ドライバー。これにより、仮想マシン(つまりEC2インスタンス)が基盤となるブロックデバイス(従来はsda、sdb ...からxvda、xvdb ...、[...]にマップ)にアクセスできます。
最後に、 Amazon EC2で接続されたボリュームにアクセスする方法 へのcyberx86の回答は、このデバイスの命名の不一致とその対処方法の詳細かつ図解された説明、つまり現在利用可能なデバイスの特定などを提供します。
注:この質問は、12年8月24日に既に回答されていましたが、6回の賛成票のある回答は、13年5月1日にCommunity Moderator( (つまり、それぞれの自動化プロセス)非透過的な理由(明らかにユーザーが削除されたため)-とにかく、私は少しのバリエーションを追加しました私の観点から元のコンテンツ。