私は自分のラップトップといくつかのサーバーにSamsung SSDを持っています。
私がする時:
smartctl -a /dev/sda | grep 177
理解できない結果が出ます。ここではいくつかの例を示します。
# my laptop Samsung SSD 850 EVO 500GB (new)
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
177 Wear_Leveling_Count 0x0013 100 100 000 Pre-fail Always - 0
# server 256 GB, SAMSUNG MZ7TE256HMHP-00000
177 Wear_Leveling_Count 0x0013 095 095 000 Pre-fail Always - 95
# server 512 GB, SAMSUNG MZ7TE512HMHP-00000 (1 year old)
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 99
# server 512 GB, SAMSUNG MZ7TE512HMHP-00000 (suppose to be new)
177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 99
# server 480 GB, SAMSUNG MZ7KM480HAHP-0E005
177 Wear_Leveling_Count 0x0013 099 099 005 Pre-fail Always - 3
# server 240 GB, SAMSUNG MZ7KM240HAGR-0E005
177 Wear_Leveling_Count 0x0013 099 099 005 Pre-fail Always - 11
Wear_Leveling_Count
の読み方
最小値、最大値があります。
"laptop"のSamsung SSD 850 EVO 500GB
を考えると、それは0で、おそらく100になるでしょう、そして失敗するでしょう。
最初の "server" 256 GB, SAMSUNG MZ7TE256HMHP-00000
を考えた場合、それはすでに最大になっていますか?それはゼロまで下がりますか?
KingstonはこのSMART属性を次のように記述しています。
ブロックあたりの平均消去/プログラムサイクル数。この属性は差し迫った消耗の指標であることを意図しています。正規化式:100 - (100 *平均消去回数/ NAND最大定格消去サイクル数)
これらの例ではRaw Data
を無視し(製造者がさまざまな方法で作業するために操作することができます)、Current Value
列を見てください。
Anandtech からのこのソースは、この図の使い方の良い指標を示しています。
ウェアレベリングカウント(WLC)SMART値は、必要なすべてのデータを提供します。現在の値は、ドライブの残りの耐久性をパーセンテージで表したもので、100から始まり、ドライブに書き込まれるにつれて直線的に減少します。生のWLC値は消費されたP/Eサイクルをカウントするので、ドライブへの書き込み中にこれら2つの値が監視されると、遅かれ早かれ正規化された値が1つ下がるところが見つかります。
すべてのドライブは95から100の間にあり、最終的には0になります。これは、各ブロックが障害を起こすまでに通過できるwrite
、erase
、rewrite
などのサイクルの数の目安です。現在の予想寿命の5%を使用したと推定されるです。繰り返しますが、ここでのキーワードは概算です。
ドライブが異なるNANDテクノロジを使用している可能性があることにも注意してください。一部のNANDテクノロジでは、ブロックがそれぞれ約1000 PEサイクル継続すると予想していますが、その他のブロックでは最大30,000サイクルの評価が可能です。
SMARTは私のSamsung SM951(AHCI)128GBのPREFAILED状態をLinuxでSAMSUNG MZHPV128HDGM-00000 (BXW2500Q)
として報告しています。
しかし私の場合は、ドライブのファームウェアのバグだと思います。
total-bytes-written
プロパティが1.1TBと報告されているのに対し、ドライブには75TBの書き込み総バイト数(TBW)が指定されているためです。 実際の耐久テストで、類似の(MLC NAND)ドライブがすべてその(600TB)倍に達するため、これはおそらく(非常に)保存側にあります 、wear_level_count
警告とは別に、他の故障前または古いエラーまたは警告は報告されません。reallocated-sector-count
は良いpre-fail指標ですが、それでも0です。だから私の忠告はあなたのドライブ/システムのためにそれらの値を調べてそれにあなたの結論を基づかせることだろう。
私は、 Gnome Disks で使われているのと同じライブラリであるskdump
と一緒に提供される低レベルのユーティリティlibatasmart
を好む。
次のコマンドを使用して、/dev/sdc
をブロックデバイスへのパスに置き換えます。
Sudo skdump /dev/sdc