ビルケンシュトックのギゼを修理に出した
最低でも6年以上履いているビルケンシュトックのギゼ。
ソールがだいぶ削れてきて寿命かなーと思ったもののオールソール張替えができると知って近所のららぽーと富士見内の店舗にて修理に出しました
交換対象はオールソール張替え+右かかと部分のコルク補充(中)
ビルケンの会員だと修理が10%割引になるので約5,000円ちょいでした。
本体の購入がABCマート特価で(たしか)4,980円だったから本体価格より修理費用の方が高いけど満足。
今の時期は依頼が多くて時間がかかるとの事でしたが2週間ほどで完了
仕上がりをまずは上から。だいぶくたびれてるのが見て取れますね
お次は横から。アウトソールとの境界に浮きやズレはなく流石の仕上がり。
手前のが右足用ですがコルク充填部分が分かるかと。
若干削れていたバンド部分も接着して貰えたのがうれしい。
ソールの接着強度もバッチリ。以前同じくオールソール交換をしたスピングルムーブは接着に不安があって、実際修理上がり直後につま先部分が剥がれて再修理する羽目に。
6年以上履いてると流石にビルケン自慢のフットベッドもカチカチなので、柔軟性のあるソールが好きという場合は修理よりも買い替えの方がよさそう
一方で今のフットベッドが足の形に馴染んでいて変えたくないという場合、ソール交換はベストな選択になりえますよ
ソールに限らずほぼ全パーツが交換対応なので、今の状態に不安があるなら近隣店舗に持ち込んで相談してみるのが良いかと
Sumsung SSD 840 120GBを使い潰す(後編)
前編と中編
負荷内容の振り返り
前編の 消耗させる の項で描いた通り、 dd コマンドで1周約111GB
及びfioコマンドで1テスト辺り10GB、シーケンシャル、ランダムそれぞれでRead,Write、及び
シーケンシャルでのreadとwriteミックスIOの5テスト、計50GBで総計約160GBの書き込みが発生します
テスト周回数とIOPSの劣化
まずはグラフをご覧ください
横軸がテストの周回数です。周回数 * 160GBがテストのでの総書き込み数になります
右軸の青線がSMARTによる Wear Leveling Count
左軸の他四色の線がそれぞれのSeq/RandのRead/Writeのfioスコアになります
fioの設定については前編をご覧ください
見所は以下のポイントになります
- 各ベンチマークのスコアは基本的には安定している
Wear Leveling Countはの減り方は書き込み量と反比例で安定しており急激に死ぬことはない- Write系は
Wear Leveling Count35, Read系は同カウント3で一気に劣化する - 劣化の傾向は同一だがSeqに比べRandomのReadは劣化後の値が安定しなくなる
グラフを作成したデータは下記のスプレッドシートを参照してください
まとめと評価
繰り返しになりますがSumsung SSD 840 120GB に対してのテストの結果
それもddでzero書き込みによる消耗が中心となる一般用途とは異なる消耗のため
全てのSSDで同じような傾向が出るわけではありません。
コントローラの特性やファームウェアでのセッティング、MLC/TLCの違い等々
ちょっとしたことで違う結果になると思われます。
あくまでこの結果はSSD消耗パターンの一事例として参考にしてもらえればと思います。
当初の想定では途中でWriteがもうちょっと大きく劣化すると予想していました。
結果は劣化幅は小さく25,000 IOPSを下回ることなくテストを終えました。
終盤Readが大幅に劣化したとはいえ、それでも最低限の速度は保っていたこともあり
個人的には通常利用では寿命の最後まで使い切れる優秀なSSDというイメージを持ちました。
寿命を使い潰した現在の状態からは使おうとは思いませんが、今お使いの方がおりましたら
是非とも残りカウント3%ぐらいまでは愛用してあげてください。
その他最新SSDでも同様のテストをやってみたいですが、給与明細を見て諦める日々が続いております
何かこのSSDを同じようにやってほしい等々のリクエストがあればコメントください。
おちんぎんで手が届きそうなら試してみます。きっと。たぶん。
Samsung SSD 840 120GBを使い潰す(中編)
前編
現状と結果
延々と回して気付きましたが Wear_Leveling_Count は 1 が最小値となっている模様
[comicsong@comicsong ~]$ sudo smartctl -A /dev/sda | grep ^177 177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always - 1240
既に 2 から 1 になる書き込み量の倍以上を行っていますが 0 になる気配は無し
まだ書き込みはできているようですが一旦これでテストを回すのは終了とします
記録について
SMART、ddコマンドによるIO、fioによる結果をログファイルに書き出していたのでそこから開始時・終了時の比較を行います
SMART値の比較
開始前
=== START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 18975 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 36 177 Wear_Leveling_Count 0x0013 083 083 000 Pre-fail Always - 200 190 Airflow_Temperature_Cel 0x0032 054 048 000 Old_age Always - 46 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 17 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 44047993640
終了時
=== START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 9 Power_On_Hours 0x0032 096 096 000 Old_age Always - 19372 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 36 177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always - 1240 190 Airflow_Temperature_Cel 0x0032 051 042 000 Old_age Always - 49 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 17 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 317487645326
Wear_Leveling_Count 以外の値に大きな変化は無し。
開始時と終了時でのIO劣化
上からシーケンシャルのread,write/ランダムのread,write/シーケンシャルのIOミックス
開始時
[comicsong@comicsong ~]$ grep -A1 -E "noop_" SMART_LOG | grep iops | head -n5 read : io=22896MB, bw=390753KB/s, iops=97688, runt= 60001msec write: io=7870.7MB, bw=134323KB/s, iops=33580, runt= 60001msec read : io=19965MB, bw=340738KB/s, iops=85184, runt= 60001msec write: io=6270.5MB, bw=107013KB/s, iops=26753, runt= 60001msec read : io=1336.2MB, bw=22803KB/s, iops=5700, runt= 60003msec
終了時
[comicsong@comicsong ~]$ grep -A1 -E "noop_" SMART_LOG | grep iops | tail -n5 read : io=9134.7MB, bw=155874KB/s, iops=38968, runt= 60009msec write: io=7615.3MB, bw=129965KB/s, iops=32491, runt= 60001msec read : io=15733MB, bw=268504KB/s, iops=67126, runt= 60002msec write: io=6068.6MB, bw=103561KB/s, iops=25890, runt= 60005msec read : io=1305.4MB, bw=22276KB/s, iops=5568, runt= 60004msec
IOスケジューラはnoopでの比較
予想ではwrite系は劣化が大きくread系の劣化は大きくないと予想していました
実際は反して特にシーケンシャルのreadが劣化しwrite系はそこまで大きくありませんでした
Read劣化のポイント
ログを確認すると徐々に落ちているのではなく625周目を境に急激に落ちていることが分かりました
count: 623 read : io=22869MB, bw=390292KB/s, iops=97573, runt= 60001msec count: 624 read : io=22908MB, bw=390953KB/s, iops=97738, runt= 60001msec count: 625 read : io=13124MB, bw=223959KB/s, iops=55989, runt= 60004msec count: 626 read : io=12345MB, bw=210672KB/s, iops=52668, runt= 60002msec count: 627 read : io=11170MB, bw=190624KB/s, iops=47655, runt= 60004msec count: 628 read : io=11141MB, bw=190115KB/s, iops=47528, runt= 60005msec
wearlevelingcountはこの前後は3 で減少無し
その他もreadの劣化は以外は大きな変動はありませんでした
詳細は次回のグラフに譲るとしてこのwearlevelingcount3がこのSSDの寿命という判断でよさそうです
簡易の整合テスト
ではまだ実際に利用できるのかの確認を
手持ちでサイズの大きい6.7GBのファイルをコピーし正常に書き込めるかを確認しました
[root@comicsong benchmark]# cp /var/www/html/epgrec/video/hoge /mnt/benchmark/ [root@comicsong benchmark]# md5sum /var/www/html/epgrec/video/hoge /mnt/benchmark/hoge 37e025122a3755563279ca68dbb5e659 /var/www/html/epgrec/video/hoge 37e025122a3755563279ca68dbb5e659 /mnt/benchmark/hoge [root@comicsong benchmark]# sha512sum /var/www/html/epgrec/video/hoge /mnt/benchmark/hoge 5e7bae62f9b028be8e26aaa3fd337dc168a065417a1f684f212d261b4f6690984bd19d048b5c059238976c101e45945b876c72a2512f69ea254eb1aae824d5e5 /var/www/html/epgrec/video/hoge 5e7bae62f9b028be8e26aaa3fd337dc168a065417a1f684f212d261b4f6690984bd19d048b5c059238976c101e45945b876c72a2512f69ea254eb1aae824d5e5 /mnt/benchmark/hoge
意外にも問題なくコピー完了。不整合も無し
寿命切れのSSDを継続使用することは無いとは思いますが即全データ死亡ともならないようです
次回は後編として、ログ内容をスプレッドシートでグラフにしようかと思います
