GalliumOSのシャットダウン時にStandby Immediateコマンドを発行してくれないみたいなのでSSDのマウントを同期書き込みに変更する

Posted by 雅楽斎 on Sunday, September 19, 2021

TOC

交換後のSSDのS.M.A.R.T値を確認していたら妙なことに気付く

SSDを交換してもらって、もう一度同じようにGalliumOSをインストールして使っています。

Acer Chromebook C720にGalliumOS3.0をインストールする

M.2 SSDをRMA手続きで交換してもらいました。Transcend製SSDのS.M.A.R.T確認からRMA手続きまでまとめます。

Acer Chromebook C720のSSDを交換してOSインストール後に作業環境として再セットアップした記録(GalliumOS 3.1/Xubuntu 18.04)

稼動状況は順調で、当面は軽作業用に使うには問題なさそうではあるのですが、元々S.M.A.R.T値が異常だったことを確認してRMA交換してもらったので、ある程度稼動してS.M.A.R.Tが正常なことを確認しないとダメですよねという話。

Linux(Ubuntu)でのS.M.A.R.T確認方法

smartmontoolsというユーティリティをインストールして値を確認するのがLinuxでの一般的なS.M.A.R.T値の確認方法ですが、今回はsmartmontoolsの結果をGUIで確認できるGSmartControlを使います。(Ubuntuのgsmartcontrolパッケージは依存パッケージにsmartmontoolsが入っているので、smartmontoolsをインストールしなくても自動的に入ります)

# apt-get install gsmartcontrol

メニューに登録されるgsmartcontrolを起動するとrootで起動するためにpkexecが起動するので、実行ユーザーのパスワードを入力します。

GSmartControlを起動するとデバイスの一覧が表示されるので、S.M.A.R.Tを確認するデバイスをダブルクリックします。

Attributesタブをクリックすると、S.M.A.R.T値を確認できます。

S.M.A.R.T値を確認していくと…

RMA交換してもらったSSDが問題なく動いていることを確認していくわけです。交換前のもので特に気にしていた数値は以下の通り。

ID説明(Transcend)
0x05Reallocated Sectors Count15
0xA0Uncorrectable sectors count when read/write1
0xA3Number of Initial Invalid Blocks36
0xB2Grown Bad Block Count15
0xC0Sudden Power Count110
0xC4Reallocation Event Count15
0xC5Current Pending Sector Count15
0xC6Reported Uncorrectable Errors1

で、交換後のSSDの現時点でのこれらの値はというと、

ID説明(Transcend)
0x05Reallocated Sectors Count0
0xA0Uncorrectable sectors count when read/write0
0xA3Number of Initial Invalid Blocks103
0xB2Grown Bad Block Count0
0xC0Sudden Power Count24
0xC4Reallocation Event Count0
0xC5Current Pending Sector Count0
0xC6Reported Uncorrectable Errors0

こんな感じになっています。概ね0になっているので問題ないといえそうです。0でないものは「Number of Initial Invalid Blocks」と「Sudden Power Count」ですが、前者は初期無効ブロック数ということなので、出荷時から無効にされているブロックの数かなぁと思います(0でなくても問題はなさそう)

後者のSudden Power Countが気になったので調べました。

Sudden Power Count/Power-Off_Retract_Count

この数字が交換後のSSDでも1回シャットダウンするごとにインクリメントされることを確認したので、何を表す値なのかをググってみました。

SSDの選び方(3/5):SSDの寿命を縮める使いかた - Qiita

はじめに 前回の記事で、TBWの正体について説明しました。 それを踏まえて、この記事では、なぜTBWが使いかた(ワークロード)に依存するのか、TBWの値の大小を左右する要素は何なのかを説明し、S…

プロトコルにもよりますが、例えばSATAではSTANDBYもしくはSTANDBY IMMEDIATEコマンドを発行して、そのコマンド完了の返答がSSDから届いてから電源を落とすべきです。

ATAコマンドでSTANDBY IMMEDIATEコマンドを発行して応答が返ってきてからホストは電源を切るべきというコマンドだそうです。

SSDが非同期で行う処理といえば、ファイルの非同期書き込みとウェアレベリングが思いつきますが、ウェアレベリングはともかくファイルの非同期書き込みはマウント時のオプションで制御できるので、今回はここを設定します。

なお、基本的にはSSDのドライバやカーネルが対処するバグのようです。

The problem is with the Intel NVME driver it seems. Switching to the Microsoft standard NVME driver and turning fast startup back on does not result in unsafe shutdowns being recorded.

GalliumOSの場合、CPU種別ごとに最適化をゴリゴリにしているので、シャットダウン時の追加対応は難しそうかなと。

mount時の非同期書き込み

マウントしているファイルシステムのオプションはmountコマンドで表示できるので、早速確認します(最近だとsnapアプリそれぞれにmountしているので見づらくなっていますが)

$ mount | grep sda1
/dev/sda1 on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered)

非同期書き込みでマウントされていると、”sync”というオプションが表示されません。

/etc/fstabを書き換えてmount時にsyncオプションを追加します。

--- /etc/fstab.org	2021-07-11 13:21:49.699299937 +0900
+++ /etc/fstab	2021-07-11 14:35:37.181377712 +0900
@@ -6,4 +6,4 @@
 #
 # <file system> <mount point>   <type>  <options>       <dump>  <pass>
 # / was on /dev/sda1 during installation
-UUID=c9d2ad18-62f8-4ecc-9b8f-f2369499c42c /               ext4    discard,relatime,errors=remount-ro 0       1
+UUID=c9d2ad18-62f8-4ecc-9b8f-f2369499c42c /               ext4    sync,discard,relatime,errors=remount-ro 0       1

OSを再起動して確認します。

$ mount | grep sda1
/dev/sda1 on / type ext4 (rw,relatime,sync,discard,errors=remount-ro,data=ordered)

syncが追加されました。

スポンサーリンク


comments powered by Disqus