AmazonEC2でUbuntuマイクロインスタンスを実行しています。
最近ログインした後、私は警告を受けました:
*** /dev/xvda1 will be checked for errors at next reboot ***
init 6
を使用して数回再起動しましたが、ログオンしても同じ通知が表示されるため、起動時にfsck
が実行されていないようです。
このブログ投稿 を読みました。これは、/ etc/fstab <pass>
列が0
に設定されている場合、再起動時にディスクチェックがスキップされることを示しています。これが私のfstab
ファイルです。
<file system> <mount point><type><options><dump><pass>
LABEL=cloudimg-rootfs / ext4 defaults 0 0
/dev/xvdh /vol xfs noatime 0 0
これは、ec2イメージfrom ubuntu
のデフォルト設定です。
<pass
>が0
に設定されるのは正常ですか?0
に設定されるのですか?fsck
を実行する最良の方法は何ですか?この値を変更する必要がありますか、それともアラートが発生したときに手動でのみ実行する必要がありますか?なぜ0
に設定されるのですか?
これにはいくつかの理由が考えられます。
EC2で実行しているため、ハードウェア(ストレージとコンピューティングインスタンス)は仮想化されます。このような構成でファイルシステムの破損を引き起こすような障害が発生する可能性ははるかに低く、ストレージの実際の物理的な欠陥(磁気ストレージの不良ブロックなど)はほぼ不可能です。
つまり、ファイルシステムの問題はそれほど一般的ではないため、ファイルシステムのチェックはそれほど頻繁に行われる必要はありません。おそらく、問題が疑われる場合は、手動でfsckを実行する必要があります。
EC2は、読み取り専用のルートファイルシステム、またはインスタンスの起動時に固定状態を復元する少なくとも1つのルートファイルシステムを持つことを「意図」しています。 EC2の主な利点は、小さなインスタンスをオンデマンドで起動し、需要が低下したときにそれらを終了し、常に同じOS構成を実行できることです。そのような状況では、ルートfsをチェックしても意味がありません。これは、ルートが変更されることはないためです。これは、システムを「開発」または一般的な用途に使用する場合には明らかに当てはまりませんが、AmazonがEC2を真に意図しているとは思いません。
EC2でfsck
を実行すると、帯域幅とプロセッサパワーが無駄になります。これは、ユーザーとAmazonの両方のコストに変換されます。
ここで<pass>
が0
に設定されるのは正常ですか?
1
はLinuxの新規インストールでは一般的だと思いますが、ディストリビューション固有の場合もあります。 Amazonのビルド済みEC2イメージも、EC2に合うように事前構成されています。
fsck
を実行する最良の方法は何ですか?この値を変更する必要がありますか、それともアラートが発生したときに手動でのみ実行する必要がありますか?
どちらのオプションにもメリットがあります。頻繁に再起動する場合は、ボリュームのマウント数を頻繁に増やすのではなく、手動で実行することをお勧めします。
余談ですが、ルートfsが通常、マウント後(fstab
が使用可能になったとき)にチェックされるのか、マウント前にチェックされるのかはわかりません。以前の場合、「典型的な」Ubuntuインストールは、ルートfsをマウントする前に、実際にはfsck
でinitramfs
を実行する可能性があります。その場合、initramfs
はEC2で異なる可能性があり、ファイルシステムをチェックする必要があることを示唆するフラグを無視する可能性があります。