今回は、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)監修のもと掲載しています。
元記事は、こちら