2013
11
01

Ubuntu 13.04 システム SSD 化のメモ

mSATA_Samsung.jpg

ubuntu のシステムドライブを SSD に変更してみました。
その変更に伴い、幾つか SSD 向けチューニングとその実効についても検証。
また利用した mSATA SSD と、同 2.5" SATA アダプターについても触れてます。

たぶん ubuntu 12.04 以降と、同系 Linux Mint 共通の内容にもなるでしょう。

○ ubuntu 環境の SSD 化について
ubuntu 環境では、仮に容量 16GB でも必要十分で 32GB なら少し余裕あり。
加えてフルシステムのバックアップにも、小容量の方が(かつ高速ならなお)好ましい。
単純な『 SSD =速い』以外にも利点が有るというのが、構成変更の主な理由。

なお容量比コストとしては 64GB 以上の方が良好ですが、相応の予算投入なら
同容量 x2 購入し、相互に Secure Erase + dd コピー(バックアップ)を提案します。
っていうか、低容量は価格ではなくバックアップ速度重視の方向性です。


○ SSD インストールでの 32bit / 64bit ( UEFI ブート)種別に関して
まず ubuntu システムの SSD 化に際し、試用数ヶ月間に好適な種別を探った話から。
結論から言うと、 x86_64 ( 64bit )の「非 UEFI 」が最適に感じます。
ざっと採択事由は以下。

☆容量について
ia32-libs 適用だと x86_64 の方がやや大きい( 5GB 前後)が、その差は些少。
☆動作について
単一アプリ動作に差は無いらしいが、起動速度や複数アプリ稼働時の動作体感において、
32bit版は僅かながら劣ると感じる。
☆ UEFI ブートについて
SSD 環境での UEFI 起動は明確に遅く、その種のメリットは皆無。


○今回使用のデバイスとか
今年の流行らしいので、今回は mSATA モノをポチってみました。
(コレ系の最新モードは、さらに小型の「 M.2 規格」に移りつつあるらしい)
現物は+アダプタ基板でも「フリスクサイズ」と呼べる小ささ。
アダプタ or 変換ケーブルでやや割高にはなるが、単純にこのサイズは魅力かも。

動作環境
M/B Intel H61BE
CPU Core i5-2500T
RAM DDR3-1333 8GB

MZMPC032HBCD_disk.jpg
Samsung MZMPC032HBCD-000L1 / 32 GB (ファーム : CXM13LQ1)
入手してみたら、 SATA 6G / TRIM / S.M.A.T. 対応の製品でした。
稼働の実効速度から察するに、 sqRead 440MB/sec ぐらいのスペックかな。

参考:おそらく同等スペックの市井流通品
MyDigitalSSD BP3 50mm SATA III (6G) mSATA 32GB キャッシュ128MB
MyDigitalSSD
売り上げランキング: 142,395


で、追加購入したアダプターがコレ。
ググったら同型らしき基板製品の評判が良く、割とリーズナブルだったのも決め手。
なお、 mSATA 呼称には mini-SATA 品と Micro-SATA 品があるので注意。




○パーティション設定について
GParted_32GBmSATA.jpg

基本的には、 x86_64 (非 UEFI )標準の自動設定のままで問題なし。
システム領域に不足はなく、 SSD 効果で「休止」復帰も速いので、その面でも推奨。
ただし RAM 2GB 以上で「休止」させない(標準は未適用)なら、拡張= Swap 領域は非作成
(または削除)でも構わないとは思います。


○ SSD 環境への ubuntu チューニングとか
以下ひと通り試しての結論としては、 SSD に特別な設定は一切必要ない感じ。
気になる TRIM 命令(≠ discard )も、 Linux では「非推奨」となっています。
でもまぁせっかくなので、幾つかの導入内容と実効を紹介。

※ 2014 年 3/9 追記
TRIM ( discard )非適用のまま、四ヶ月を経て Fedora 20 へ移行しました。
容量 / 利用比はやや厳しめだったので、相応に速度低下はあったのでしょう。
ただし HDD 環境との比較を含め、体感での速度低下は全くありません。

でもまぁ ubuntu 14.04 では標準だし、 Andoroid なんて自動で定期実行される。
何にせよ SSD 専用チューニングなんてのは、そろそろ過去の見識ってことで。

っていうか、現在 TRIM に discard は使いませんね。
fstrim (実際には util-linux の一部)を実行します。


☆設定その 1 ; mount オプション
/etc/fstab へマウント・オプションを追記編集して、設定を変更。
主目的は(確実性を捨てての)高速化ですが、若干の書込量低減もあるらしい。

仮に下記フルオプションで該当内容を書き換えすれば、以下例(青字)に。
UUID=00000000-0000-0000-0000-000000000000 / ext4 discard,data=writeback,noatime,nobh,errors=remount-ro 0 1

各オプションの効果
writeback :ファイルシステムを速度重視のモードにする ※注 1
nobh :バッファとデータの関連付け ※注 2
noatime :最終アクセス時刻の更新を止める
discard : 「廃棄」オプション= TRIM のサポート ※注 3

※注 1 : オプションの前に、以下ジャーナル変更をコマンド適用のこと。( dev 名は各環境で)
sudo tune2fs -o journal_data_writeback /dev/sda1
※注 2 :同オプションは writeback との併用設定
※注 3 :原則非推奨とされ、また常時実行では I/O 低下の可能性も。(下記参照)

Impact of ext4′s discard option on my SSD
https://patrick-nagel.net/blog/archives/337

よって同オプション付加に際しては、 cron による定期実行が推奨される模様。
Enable TRIM On SSD In Ubuntu For Better Performance
http://www.webupd8.org/2013/01/enable-trim-on-ssd-solid-state-drives.html

ともあれ自己環境には writeback , nobh , noatime のみ試採用。
ubuntu では数ヶ月でシステム刷新かもしれない上、望む動作をしない可能性のある
TRIM ( discard )をあえて使う必然も、対効果も、かなり薄いと判断。
何よりごく単純に、実効させたいタイミングで追記すりゃ済むんじゃね?って気も。


◎マウント・エラーが出た話(失敗談)
web 情報をナナメ読み実行したら、「※注 1 」内容によって ubuntu が起動出来ないトラブルを発生させてしまう。
無論ミスには違いないが、 Linux ではこうした「ダメ、絶対!」な実行内容も警告なしに通ってしまうとこが「人に勧められない」理由の一つかも。

という訳で初心者向けの復旧法
SSD 接続のまま ubuntu の Live CD / USB 起動し、 Dash ランチャーに「ボリューム」として認識されている SSD をクリック(マウントする)。
後は端末起動して「 sudo nautilus 」や「 gksu gedit 」コマンドから SSD 上の
fstab ファイル内容を初期状態に書き戻す等すれば、復旧。
ファイル取り出し等にも応用できるので、覚えておいて損はないかと。

◎マウントオプション実効による速度変化
ここで Bootchart を使い、起動速度の変化等をデータ確認してみた

SATA 3G 接続、オプションなし起動
SATA3G_normal.jpg
起動時間 約 20 秒
ディスクスループット 約 270MB/sec
未計測ですが、 Read 100MB/sec HDD 起動での体感は 30 秒ぐらいかな?
強いて挙げれば Windows では「起動時」に最大の効果を感じるが、 ubuntu では
順当に稼働での「ファイル読み書き動作」に対し、より速さを感じる。


SATA 3G 接続、 writeback , nobh , noatime 適用
SATA3G_fstab_OP.jpg
起動時間 約 17 秒
データは一応 3 秒ほど低減だけど、同時確認でもない限り体感は難しいレベル。


SATA 6G 接続、 writeback , nobh , noatime 適用
SATA6G_fstab_OP.jpg
起動時間 約 17 秒
ディスクスループット 約 380MB/sec
H61 標準は SATA 3G だけど、 SATA 6G チップもオンボなので計測。
Windows も同様だけど、速度が多少向上しても起動時間は頭打ちなのが判る。
ただ動作体感の方は明確に向上なので、高速 SSD の効果はアリ。


☆設定その 2 :一時ファイルを RAM ディスクへ
これも /etc/fstab への追記で高速化と書込低減を図る設定。
理屈上は「速くなりそう!」だが、少なくとも単体設定では体感出来るか?微妙。

追記内容としては以下
tmpfs /tmp tmpfs defaults,noatime 0 0

記述では容量指定していないので、搭載 RAM の半分を割り当てらしい。
RAM 量が厳しい場合は、適用しないか適切な容量を指定のこと。

なお同様に /var/tmp を tmpfs 化する設定は FHS 違反かつ、状況により再起動で読み込まれる場所ということで、トラブル直結の可能性があるっぽい。
という訳でコッチは非採用。


☆設定その 3 :キャッシュのディスク書込み頻度を低減させる
/etc/sysctl.conf への記載でページキャッシュの書込間隔を伸ばすもの。
結果的にディスク書込量を減らす内容になるらしい。

書込内容は以下 (標準の 0.5 秒毎を、 1.5 秒毎の値に変更:単位ミリセカンド)
vm.dirty_writeback_centisecs = 1500

コレ・・・効果はさておき、 記述数値ではちょっと間隔が長すぎるのかも。
何気ないペースで変更・更新⇒即再起動したら、データ消失があってイラッとした。
最小 10ms 単位の設定らしいので、各々で最適値を探って下さい。


☆設定その 4 :高精度イベントタイマーの適用
grub 起動オプションの変更から、 I/O 処理の効率化を図る設定。
tsc 比など実効への見地には論議があるらしいけど、個人的には良い!と思った。

変更には PC の HPET 対応が前提なので、以下コマンドを実行
code:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
結果に「 hpet 」が含まれることを確認。

対応なら /etc/default/grub を直編集し、設定。
同内容には
GRUB_CMDLINE_LINUX=""
があるので、ココを
GRUB_CMDLINE_LINUX="clocksource=hpet"
に変更。

その後下記コマンドを実行して有効化。
sudo update-grub2
sudo reboot


☆設定その 5 : Preload の活用
設定としては、 Windows XP で言う prefetch 相当の機能にはなると思う。
ただし実効体感としては、同 Vista 以降の SuperFetch に全く及ばない気がする。

ちなみに HDD 構成でも二ヶ月ほど常用してみたが、ほぼ有効性を体感出来ず。
よって特に推奨せず、適用法も割愛。


◎まとめ
売れ筋から外れる 32GB クラスの SSD は多少割高だが、投資額としてはミニマム
なので、割と手軽なアップグレードになるはず。
またこのクラスの mSATA については、最新構成で「速い」モノが多いらしく、この点は
やや旧態構成の混ざる 2.5" 形式製品に対し、アドバンテージかもしれない。

なお各種「 SSD 向けチューニング」とされる内容は、元来「サーバ向け I/O チューニング」の抜粋で効果もあるのだろうが、体感は「速い SSD 」には及ばない。

何より SSD に対し「より速く or 書込寿命対策に」といった特殊な手法自体、
もう旧い見識に感じるので、 Linux 側での「標準対応」を待つべきかと。

もし書込領域の不足⇒速度劣化が気になるなら、より大容量の SSD を使うか、
SSD x2 を用意して、常に片方を Secure Erase の方が手っ取り早いハズ。


まぁ mSATA は基板むき出しだし要アダプターだから、一般的にはこの手かな。
Windows 環境での需要の低さから、むしろ価格は上昇傾向なので周辺相場は確認のこと。





スポンサーサイト

«  | HOME |  »