今回は、fsckは定期的に必要だと感じた出来事を紹介します。
長い間、起動しているEC2(linux)があり、テスト用に同環境を作ろうと、下記のような作業を行いました。
EBS(スナップショット)→AMI作成 →起動
構成は下記のようになります。
rootディスク 10GB /dev/sda1
dataディスク 100GB /dev/sdg
作成したAMIから起動したのですが、一向に立ち上がらず、コンソールからsyslogみると/dev/sdgがマウントできないというようなエラーが出ていました。
※すみません、実際のエラー内容をメモしていませんでした。
データディスクの方が悪いので、EC2起動不能からの復旧記録を参考にして、別のEC2にrootディスクを仮マウントして
/etc/fstabからdataディスクを起動時にマウントしないようにコメントし、元のEC2にアタッチし直して起動したらすぐに起動しました。
また、mountできるかここで試したらすぐにマウントできました。
急いでるときはこの方法が早そうです。
/etc/fstabを戻し、インスタンスをストップすると、恐らくまた立ち上がらない可能性があるので、dataディスク100GB /dev/sdgの方をfsckしてみました。
すると、このfsckが1時間半程かかりました。
/dev/sdg has gone 314 days without being checked, check forced.
上記のように、1年近くfsckをしていなかったようです。
[root@app1 ~]# fsck -y /dev/sdg fsck 1.39 (29-May-2006) e2fsck 1.39 (29-May-2006) /dev/sdg is mounted. WARNING!!! Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. Do you really want to continue (y/n)? yes /dev/sdg: recovering journal /dev/sdg has gone 314 days without being checked, check forced. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Free blocks count wrong for group #158 (9510, counted=9512). Fix? yes Free blocks count wrong (14550268, counted=14550270). Fix? yes /dev/sdg: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdg: 1254158/13107200 files (29.6% non-contiguous), 11664130/26214400 blocks
このように、長く立ち上げてるEC2のEBSについては、定期的にfsckをした方が良いと思いました。
冗長化しているものならできますが、シングル構成のものだとなかなかサービスを止めることができないので、定期的に再起動などしてfsckすることを計画しましょう。
こちらの記事はなかの人(kenjionsoku)監修のもと掲載しています。
元記事は、こちら