作者: williamlaw 時間: 2024-11-9 13:18 標題: 硬盤狀態問題
安裝左 Scrunity 去 monitor HDD status, 發現 Scrunity 同 DSM 入面既硬盤狀態不同
現在情況, SATA3真係有問題嗎 ?
THANKS
https://h2.hkepc.com/forum/attachment.php?aid=2450971&k=9f2650dc759b513517cb60f60e650c2d&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2450972&k=a9e1e69ac3747384e88dfedbf4f3d9c6&t=1781510818&sid=484AOZBLBO

作者: pbodq 時間: 2024-11-9 17:01
唔expand個attribute table睇下鬧你乜?
點估? 作者都無可能答到你
作者: williamlaw 時間: 2024-11-9 23:42 標題: RE: 硬盤狀態問題
就是這樣
https://h2.hkepc.com/forum/attachment.php?aid=2451108&k=b5c48d7f5e22d51fd1309dc8af904ef6&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451109&k=846d6a25c9f2fb423c92d7e632c2edc5&t=1781510818&sid=484AOZBLBO

作者: 9658@transperth 時間: 2024-11-10 00:26
回覆 3# williamlaw
C5同埋C6都已經出咗問題啦
嗱嗱聲去做backup
作者: pbodq 時間: 2024-11-10 00:33
本帖最後由 pbodq 於 2024-11-10 00:37 編輯
回覆 3# williamlaw
兩類紅色的sector count有料
實際raw value無寫, VALUE column係normalized 100%後的表達式, 我見人地張Scrunity screen shot 有得raw value
不過點都無所謂, DSM6會當這兩類sectors係老化跡像及歸類為bad sectors, 但DSM7唔當, 所以唔鬧你。
類似感冒, 有d醫生會好緊張, 死得人, 但有d人當小病讓它自然好
至於成因
可以碟片自然老化產生silent corruption > 磁頭自然老化 > 電源質素令磁頭損毀 > OS bug寫入錯誤data
甚致四個原因複合產生
DSM7唔當係問題, 原因1+4可以重塑磁顆粒分佈, 有機會變回正常, accumulation error 未達廠方定義的reallocation threshold (以100% normalized 表達)
DSM6有殺錯, 無放過
至於2+3會大量產生counts, 其他attributes會直接反映failure
你唔放心就換碟lor
我有d pools由於有data correction, 可以從另一隻碟real time scrubbling修正
所以我就唔理這類問題, 你見我另一個post隻碟係有bs都照用
https://www.hkepc.com/forum/redi ... 06&pid=42405047
昨日仲特登賣走隻全新未拆封的碟
https://www.hkepc.com/forum/view ... 5679&highlight=
----------
至於兩項橙色, 唔習慣Scrunity的表達式, 畀唔到意見
作者: rabbit82047 時間: 2024-11-10 10:28
c5, c6 一有數字,樓主都係準備換碟啦
作者: williamlaw 時間: 2024-11-10 11:46
請問出紅色就換定安全啲?
另外換碟程序係一拔一插就可以? 還是要先停sata3 再換
Thanks
via HKEPC IR 5.1.14 - iOS(5.1.1F)
作者: madebyp90 時間: 2024-11-10 12:21
你問得嘅話
建議你都係backup定先好搞
作者: williamlaw 時間: 2024-11-10 14:58
本帖最後由 williamlaw 於 2024-11-10 15:00 編輯
如果先 disable sata3 再換呢?🤔
via HKEPC IR 5.1.14 - iOS(5.1.1F)
作者: pbodq 時間: 2024-11-10 22:30
回覆 9# williamlaw
一句講晒, 所有支援Hot N Plug 的SATA devices, 都必須先停用 (發出STANDBY/SLEEP, byte code _E2H/_E6H), 才能抽出
要講得複雜的話
兩個插頭所有三十幾支針腳, +-VCC必定是最長的腳, 在插入及抽出時, 是受到最先觸發/滿足的條件, 以確保其他低電平的訊號腳能在安全條件下移除/運作, 但係人手掁動力會在磁臂未趕得切收到斷電回位訊號時(約0.7mm間距)令磁臂抖動, 從而產生物理損毀。
作者: williamlaw 時間: 2024-11-11 08:26
回覆 williamlaw
兩類紅色的sector count有料
實際raw value無寫, VALUE column係normalized 100% ...
pbodq 發表於 2024-11-10 12:33 AM
請問DSM7 要去到邊個階段先會報 fault ?
例如硬碟完全 detect唔到先報 ?
via HKEPC IR 5.1.14 - iOS(5.1.1F)
作者: pbodq 時間: 2024-11-11 14:55
本帖最後由 pbodq 於 2024-11-11 15:17 編輯
回覆 11# williamlaw
1.pre-fail類型的attribute過threshold%佢會報fail
attributes分三column類, prefail (預告壞碟), aging(老化, 效能降), 跟前兩者無關(例如C7)
只有prefail類才會有廠方定義的%threshold
2.harddisk firmware非受HBA管控的簡測/長測fail,佢亦會報fail, 因為SMART有entries log fail
打一次smartctl就清楚晒, 事實上Scrunity對smartctl的調用及json解譯有時唔暢通, 我d碟在7.2.2佢係完全access唔到, 最後都係手動smartctl, 感覺佢只係介面靚及有通訊功能優點, 在可信準確度及可靠度來說, 感覺麻麻
--------
detect唔到, 就直頭報唔到
-------
紅色的兩項, 如果你無像我那樣的data correction的pools, 那些超時的sectors上的數據其實已經錯亂了, 即使日後它們重寫變為健康, 但在當下這刻, 是讀不出正確的data
但唔知你堆pools乜狀況, 有無開校檢推算等等 >> 同一個pool1, RAID5/6? RAID10? ?????????係的話就check一次
DSM7 > 硬碟self mode簡測 >> 如果fail, 就換碟
如果不是fail >> 行一次scrubbling修正數據 (假設是RAID), 如果結果無容錯功能, 你都係換碟rebuild。若能修正,可繼續用。
作者: williamlaw 時間: 2024-11-11 17:28
回覆 williamlaw
1.pre-fail類型的attribute過threshold%佢會報fail
attributes分三column類, prefail ...
pbodq 發表於 2024-11-11 02:55 PM
"硬碟self mode簡測" 即 "SMART 快速檢測" ?
SMART 快速檢測 結果仲係"良好"
聽你地咁講, 真係要deploy番個 Scrntiny 去 monitor 住HDD 先得, DSM既 SMART 靠唔過
[attach]2451340[/attach]
https://h2.hkepc.com/forum/attachment.php?aid=2451342&k=c151af544cec7006e33fecabe9e9991d&t=1781510818&sid=484AOZBLBO

作者: pbodq 時間: 2024-11-11 20:00
"硬碟self mode簡測" 即 "SMART 快速檢測" ? >> yes
SMART 快速檢測 結果仲係"良好" >> 咁就行一次array data scrubbing, 大概3天左右, 已經包晒host mode full media read。正常當DSM detect到有silent corruption時, 會立即overwrite 修正, 並且發出emails/notifications。再看看統計表, 如果修正了, 基本可以繼續用。
pending(存疑) sectors的行為定義在大多數廠商firmware:
當該sector實體數據hash值不等同該sector ECC的checksum時, 代表數據已變質, 可能磁頭問題多或多數是顆粒感應問題, 這時會多花幾秒嘗試修正(撞/估), 如果不成功, 會在SMART記下一次該LBA的pending及uncorrectable (修正失敗)的count。這是harddisk firmware的處理行為
然後向DSM回報該sector出錯, 如果你是行array, DSM會從其他member disks推算出該sectors的正確值, 然後馬上overwrite一次, throw出"發現並修正"該LBA的notification / email (DSM7未改版之前), 這一步是OS層面的處理方法。這時候SMART唔會因為DSM overwrite左而減少SMART pending/uncorrectable 的counts, 因為即使重寫了, 亦唔代表能真係正確讀回, 只能算是努力嘗試
直至到該sector重新被讀取成功(合乎ECC checksum), firmware才會減少pending counts, 把這個LBA從watching list移除。
假若不好彩, 再次讀取該sector時, 仍然出錯checksum, 這就有趣了, firmware有兩種不同的處理情況
1.假若該sector是之前重寫過而又重讀失敗, 能滿足這個cycle達n次頻率, 就會把LBA撥到SMART的05健康sector。至於n值是多少? 不同廠不同grade的定義不同, 例如我圖中隻WD企業, 大概3次就會撥, 但home級如紫碟紅碟, 差不多要等足10次
2.假若數據無被重寫, 只是單純不停地重讀出同一個corrupted sector, 係唔會觸發firmware撥備, pending count亦唔會改變
如果你唔熟呢d野, 判斷唔到情況, 換碟當係最簡單, 6TB好鬼平, 不過最煩的反而係backup。
因為換碟時, 你又要確保其他array member disks無corruption。你最好都係先全面評估一下, 做一次array校驗再算
作者: williamlaw 時間: 2024-11-11 20:13
請問「Array校檢」需要點做?
via HKEPC IR 5.1.14 - iOS(5.1.1F)
作者: pbodq 時間: 2024-11-11 20:37
回覆 15# williamlaw
.............

https://h2.hkepc.com/forum/attachment.php?aid=2451373&k=faefa0ebc4db135c04dca99f71a1ec15&t=1781510818&sid=484AOZBLBO

作者: williamlaw 時間: 2024-11-11 22:09
感謝
其實有需要定期run一次嗎 ?
via HKEPC IR 5.1.14 - iOS(5.1.1F)
作者: pbodq 時間: 2024-11-12 03:04
本帖最後由 pbodq 於 2024-11-12 03:18 編輯
回覆 17# williamlaw
我就唔set schedule, 覺得有需要才manual run
1.full read所有碟, 太費時間, 而且utilization高, 其他I/O dependent的software會變得好慢, 甚致因太慢而halt
2.抽碟需要事前全面評估, 避免抽碟後, 有其他member disks同時出error, 所以最好掃一次silent corruption ; 平時齊碟, 當我讀到某個file的corruption, 係會被發現並自動修正重寫, 而我又覺得d碟仍然健壯, 我就唔會主動去掃corruption出來。呢樣野憑經驗, 你鍾意的話, 可以set schedule。好似body check咁樣, 有d人自問好健康, 好有信心, 係唔做body check, 除非有大徵兆。
***忘了說最重要的一個前題:假設你有enable self-healing
而做一次full backup, 都係經過了一次full read scrubbing checksum, 但係你要搵18TB 空間儲起佢
(單純兩三個pending sectors其實好濕碎自然的現象。 除非壞磁頭及servomotor, 由兩三個變幾百個, 咁就大鑊野。而壞磁頭及servomotor就唔止單純出05c5了, 連帶01, 07,200,205都會同時暴增。相對來說, 這四項的強性關聯會比05c5對於判別硬碟的健康及可靠度更具指標功能)
------
我其中一個post話兩項橙色無show raw data, 意思係叫你最好爆開個table detail, 了解一下, 因為佢表達好唔完整, 我見Google係有raw value screenshot。
假設04 (Start/Stop) 27% current value壽命, 20%警戒線, 咁你就真係好大鑊, 但呢樣通常係count馬達的起動次數, 通常單位係直觀十進制, WD係唔會define threshold%, 我就唔知Seagate點計。raw value太密即代表電源線鬆/金手指氧化/接觸不良/電壓不穩/紋波電流扞擾, 不停斷合。
我圖中有bs果隻WD, 行了7年,都只係斷合過80次咁大把
至於你個case, 都係對比一下其他碟這項的raw value再算la, 最好搞清楚個full picture
https://h2.hkepc.com/forum/attachment.php?aid=2451405&k=06f0bdb509240310e2961c66d08dd8af&t=1781510818&sid=484AOZBLBO

作者: williamlaw 時間: 2024-11-12 14:15
回覆 williamlaw
我就唔set schedule, 覺得有需要才manual run
1.full read所有碟, 太費時間, 而且uti ...
pbodq 發表於 2024-11-12 03:04 AM
1) run 完 data scrubbing, 原來 ID 197-198 變左pass (60-70% 變 3%), 但 ID 187 又變左 failed.
- 其實代表要換硬嗎 ?
- 另外Scrutiny入面最主要睇邊幾個值去決定HDD狀態 ?
2) 對比另外3隻碟, ID 3-4 數值都差不多
SATA1
SATA2
SATA3
https://h2.hkepc.com/forum/attachment.php?aid=2451452&k=b399ff04128f78bc77ff93b942918e33&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451453&k=ce67f468acc58fa4631bab6dac110767&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451454&k=0f4c2e7e2468142fdceccfa725c3a4da&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451455&k=dbad9d01dd181ce364d50b50d4922911&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451456&k=b7407dc6035329aebb6d31ed11375cd6&t=1781510818&sid=484AOZBLBO

https://h2.hkepc.com/forum/attachment.php?aid=2451457&k=041c9ba6c80bfb5f645c59b3be2b99f9&t=1781510818&sid=484AOZBLBO

作者: pbodq 時間: 2024-11-12 17:30
1) run 完 data scrubbing, 原來 ID 197-198 變左pass (60-70% 變 3%), 但 ID 187 又變左 failed.
- ...
williamlaw 發表於 2024-11-12 02:15 PM
- 其實代表要換硬嗎 ? >>
我就唔換著, 果幾個壞死的sectors已經被scrubbing rewrite返正確data上去並且能正確讀回後清零SMART, 如果由pending remap撥去ID 05 reallocation就更加安心, 永安唔會再touch到。
當然, 如果你要換就更安心, 其他3隻碟無bad sectors, 你就唔使驚rebuild 時lose data
但我始終搞唔清楚佢ID 04條數點走出來: 27,20,11%, 就咁表面比較數值, 我當佢fault alert, 唔似之前猜測關於通電接觸不良的問題, 只是單純碟片sectors的自然老化, 跟DSM7認為隻碟屬於健康狀態這個結論一致。
- 另外Scrutiny入面最主要睇邊幾個值去決定HDD狀態 ? >>
無認真用過Scrutiny, 答你唔到, 除左每個軟件都用的mechansim1 (這個由每間廠方提供, 絕對可靠) ; d人話佢仲識搵大數據的database做關係性比率的比對, 唔知係咪fail rate column的意思
https://github.com/AnalogJ/scrut ... ecomment-1125654536
作者: pbodq 時間: 2024-11-12 18:48
回覆 20# pbodq
但我又想到一個極端情況
你四隻碟的ID4 都真係由100%跌到current 26%/27%, 如果係咁就四隻都受到供電問題影響
勸你唔好依賴Scrutiny, 直接smartctl入去望望ID4乜料
- sudo smartctl -a -d sat -T permissive /dev/sata1
- sudo smartctl -a -d sat -T permissive /dev/sata2
- sudo smartctl -a -d sat -T permissive /dev/sata3
- sudo smartctl -a -d sat -T permissive /dev/sata4
作者: pbodq 時間: 2024-11-12 20:16
本帖最後由 pbodq 於 2024-11-13 03:59 編輯
回覆 21# pbodq
做好人做到底, 幫你搵埋
呢隻5400rpm已經算係食好少電, 想用其他更省電的碟去規避問題好難, 除非揀Toshiba SMR, full load都只係5W (但這做法係掩耳盜鈴)
https://www.seagate.com/www-cont ... -8-1803US-en_US.pdf
人地正常係100% current起始健康值, raw value 跑兩年都只係四百次斷合電源
你現在已經唔係換唔換碟的問題, 亦唔係bad sectors的問題
係你的電源真係有問題, 27%......一死就陸續死四隻
所以我成日強調, 純睇ID c505去決定換唔換碟係完全無意思, 有時係白費工夫及時間, 甚致把真正的問題越蔵越深。單純的c505真係超小事, 可以簡單處理甚致唔使處理, 讓它自然好。
四隻供電同時出事的話,
如果你諗著量度火牛loading的話, 亦要做backup, 又係好煩
乾脆省工夫盲換一次火牛博一次都係一百蚊有找, 記低ID04數字, 如果日後無再彪升, 所有問題包括sector類 + 電機馬達起動都迎刃而解, 唔使理
https://h2.hkepc.com/forum/attachment.php?aid=2451495&k=6d79319fe771cc507596ae81cd69efbc&t=1781510818&sid=484AOZBLBO

作者: williamlaw 時間: 2024-11-13 10:41
順序由 SATA1 -4
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 26
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 26
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 27
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 27
作者: s84292 時間: 2024-11-13 10:54
本帖最後由 s84292 於 2024-11-13 02:58 編輯
建議去自動排程SET 3個月一次,費事唔記得
SET夜晚由佢自己做就可以,我舊個隻NAS 7年了3隻WD RED PRO 8TB日日7X24 每日讀寫100GB以上
都係每3個月行一次,都係壞過1隻碟咁大把
作者: s84292 時間: 2024-11-13 11:01
本帖最後由 s84292 於 2024-11-13 03:13 編輯
係,冇理由咁多START STOP
不過我冇開休眠)
https://h2.hkepc.com/forum/attachment.php?aid=2451589&k=31d97c2036a6aa08ec74b20fb3c06aa8&t=1781510818&sid=484AOZBLBO

作者: pbodq 時間: 2024-11-13 12:39
本帖最後由 pbodq 於 2024-11-13 12:49 編輯
順序由 SATA1 -4
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WH ...
williamlaw 發表於 2024-11-13 10:41 AM
真相大白了
raw value係26-27次起動, current normalized係超健康的100%
咁就唔使驚了, 供電非常正常, 只係零星幾個自然的pending sectors
Scrutiny fault alert, 佢將raw value column當normalized current column排列, 個橙色warning靠大數據database亂拉關係
可能我之前寫得太多字, 你睇亂左: 我係覺得DSM個result可靠過Scrutiny的判斷, 佢唯一衰是現在剦走GUI, 下下要入smartctl
作者: williamlaw 時間: 2024-11-13 14:22
最初裝既時候有enable休眠, 但一個月之後已經停左
作者: williamlaw 時間: 2024-11-13 14:25
本帖最後由 williamlaw 於 2024-11-13 14:27 編輯
真相大白了
raw value係26-27次起動, current normalized係超健康的100%
咁就唔使驚了, 供電非常正常, ...
pbodq 發表於 2024-11-13 12:39 PM
smartctl 入面, 要參考ID 05, 187, 188, 197, 198 ?
要清除 Scrutiny 入面 SATA3 fail alert, 要係 Scrutiny delete SATA3 再 add ?
作者: pbodq 時間: 2024-11-13 18:53
smartctl 入面, 要參考ID 05, 187, 188, 197, 198 ?
要清除 Scrutiny 入面 SATA3 fail alert, ...
williamlaw 發表於 2024-11-13 02:25 PM
05 >> 好奇, 最好望望, 如果有count, 已撥備就安心了, 但呢隻監控碟, 我估佢firmware唔肯咁輕易撥備, 因為佢市場目的係不停overwrite錄影sectors, 無必要儲存精準的data。05,197,198,187,188呢幾個attribute咁常用, 應該唔使入去smartctl, 我"相信"Scrutiny唔會又"對錯"column
187 >> 係一個歷史性質的value, 類似黃過留左案底, 即使改過自身, 個朵臭左就係臭左
要清除 Scrutiny 入面 SATA3 fail alert, 要係 Scrutiny delete SATA3 再 add ?>>
答你唔到, 我的Scrutiny安裝不太順利
作者: williamlaw 時間: 2024-11-14 10:45
唔詃師兄.
依家 187 value = 6, 係代表依家仲有問題 ? 定只係案底 ?
而數值去到幾大先算真係有問題
作者: pbodq 時間: 2024-11-14 11:30
依家 187 value = 6, 係代表依家仲有問題 ? >> 無, pending已清
定只係案底 ? >> 案底, 犯案次數, 正常手段來說洗唔走, 只會累加
犯案次數太多當然唔好la, 好主觀, 要連埋其他attributes評估


