我在某些硬碟上遇到了一些奇怪的錯誤，並且無法縮小問題範圍。它是 RAID 陣列（Linux 軟體 RAID，預算硬體）的一部分，因此當它從陣列中掉出時，我的第一個反應就是簡單地將其更換為備用。但重建工作一直失敗。
這些驅動器位於 5 個驅動器外部 SATA 機箱中（4 個機箱，每個機箱 5 個驅動器），我注意到該機箱也顯示出奇怪的症狀。通常，新增磁碟機後，當機櫃的 SATA 連接埠複製器偵測到新磁碟機時，指示燈會以某種方式閃爍。在重建過程中這種情況不斷發生，這對我來說意味著連接埠複製器的硬體可能是真正的罪魁禍首。
我有一個備用機箱可以解決此類問題，因此我將其更換並將驅動器放入新機箱中。但此時mdadm根本無法重建驅動器。總是失敗立即地啟動後。我嘗試了幾個不同的備用驅動器，症狀相同。當然我沒有遇到多個驅動器發生故障的情況完全相同的方式在完全相同的時間？
機櫃連接到主機中安裝的 2 個 SATA 控制器卡，每個控制器卡有 2 個連接埠。也許這是其中一張牌？因此，我移動了 SATA 電纜，使「有問題的」外殼位於另一張卡上。但同一機殼中的同一磁碟機托架仍存在相同的問題。
此時我已經沒有什麼好測試的了。我的主機中有 2 個驅動器、2 個機箱和 2 個控制器卡。它們的任何組合都會產生相同的問題。
目前mdadm正在嘗試重新建置到驅動器上（不知道為什麼這次沒有失敗），但是在顯著地速度降低。它在正常速度的 1/2 和 1/4 之間波動。更換的機櫃也會像前一個機櫃一樣重新偵測驅動器。
現在，我對診斷硬體不太了解。對於商品硬件，通常是一個更換週期。但在這種情況下，所有替換零件的行為都相同，所以我不確定什麼問題是。我一直在谷歌搜尋我看到的一些東西，/var/log/syslog但到目前為止還沒有理解太多。我可以告訴你...
當機櫃「重新偵測」驅動器時，這會顯示在syslog：
Oct 3 17:43:52 gibson kernel: [ 1478.755088] ata5: controller in dubious state, performing PORT_RST
Oct 3 17:43:54 gibson kernel: [ 1480.909415] ata5.05: limiting SATA link speed to 1.5 Gbps
其他令人不安且經常重複的消息如下syslog所示：
Oct 3 17:46:05 gibson kernel: [ 1612.163891] ata5.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x6
Oct 3 17:46:05 gibson kernel: [ 1612.163894] ata5.00: irq_stat 0x00060002, device error via D2H FIS
Oct 3 17:46:05 gibson kernel: [ 1612.163897] ata5.00: SError: { Handshk }
Oct 3 17:46:05 gibson kernel: [ 1612.163899] ata5.00: failed command: WRITE DMA
Oct 3 17:46:05 gibson kernel: [ 1612.163904] ata5.00: cmd ca/00:00:00:29:87/00:00:00:00:00/e0 tag 0 dma 131072 out
Oct 3 17:46:05 gibson kernel: [ 1612.163905] res 51/84:90:70:29:87/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
Oct 3 17:46:05 gibson kernel: [ 1612.163907] ata5.00: status: { DRDY ERR }
Oct 3 17:46:05 gibson kernel: [ 1612.163909] ata5.00: error: { ICRC ABRT }
有時是這樣的：
Oct 3 18:07:10 gibson kernel: [ 2877.073010] ata5.00: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073015] ata5.00: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073017] ata5.01: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073020] ata5.01: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073022] ata5.02: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073024] ata5.02: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073026] ata5.03: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073028] ata5.03: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073030] ata5.04: failed to read SCR 1 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073032] ata5.04: failed to read SCR 0 (Emask=0x40)
Oct 3 18:07:10 gibson kernel: [ 2877.073034] ata5.05: failed to read SCR 1 (Emask=0x40)
我還可以執行其他測試嗎？我還可以嘗試其他事情嗎？什麼可以無論使用什麼硬件，都會出現症狀嗎？
該陣列多年來一直運作良好，偶爾更換驅動器。主機上沒有進行任何軟體更改（除非我已被入侵並且不知道，這當然是可能的）。但幾個月前的一次驅動器故障導致了不斷的重建，最終讓我陷入了目前的狀態。
編輯：我剛剛意識到的另一種模式，不確定它是否意味著什麼。陣列中的磁碟機已sdb1通過sdu1。啟動作業系統並不總是以相同的順序看到它們，因此任何給定的驅動器都可能在重新啟動時更改其字母。當驅動器持續故障時立即地重建後mdadm，它是/dev/sdq1。但縱觀當前的症狀（緩慢的重建、外殼一遍又一遍地「重新檢測」它，以及基本上上面記錄的錯誤），它一直是/dev/sdu1。
編輯：我下載了 Knoppix 7.2，看看是否可以啟動陣列並在其中添加驅動器。只是想看看是否是軟體問題。完全相同的症狀。所以...更換了硬件，更換了軟體，但問題仍然存在。這讓我目前陷入了死胡同。
編輯：我也嘗試過將驅動器清除：
dd if=/dev/zero of=/dev/sdu bs=1M
但同樣的症狀仍然存在。此時我懷疑控制器可能有問題，但某種程度上我不明白。兩張卡中的每一張都可以工作，但出於某種原因，兩張卡一起無法管理這麼多驅動器？可能沒有任何意義，我只是想在這裡識別模式。
編輯：輸出smartctl -a -d ata /dev/sdu：
smartctl 5.40 2010-10-16 r3189 [x86_64-slackware-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green family
Device Model: WDC WD20EADS-00S2B0
Serial Number: WD-WCAVY0536607
Firmware Version: 01.00A01
User Capacity: 2,000,398,934,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is: Sat Oct 5 07:04:21 2013 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x84) Offline data collection activity
was suspended by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (42900) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 179 179 051 Pre-fail Always - 90370
3 Spin_Up_Time 0x0027 149 149 021 Pre-fail Always - 9525
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 22
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6170
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 18
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 9
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 610025
194 Temperature_Celsius 0x0022 117 073 000 Old_age Always - 35
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 125
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 62927
200 Multi_Zone_Error_Rate 0x0008 090 090 000 Old_age Offline - 22176
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
更新：我可能會在這次冒險中迎來第一次有希望的突破。在花了過去 6 個小時左右的時間（斷斷續續）更換驅動器/外殼/電纜/卡並系統地嘗試尋找一種模式後，我終於找到了一種模式。我能夠始終如一地重現這一點。
它不喜歡熱插拔。
它說是的。它的目的是。並且竭盡全力兌現這項承諾。但這是一個謊言。我不會假裝知道任何有關在其中發揮作用的低階硬體架構和/或核心架構的信息，但我至少可以在邏輯上確定可重現的模式。
我敢打賭，今年夏天我就開始了熱插拔災難，甚至沒有意識到這一點，而且很可能造成的結果就是這整個混亂。syslog顯示我看到的錯誤從六月開始，就在重大故障發生之前，就在我去舊金山度暑假之前，無法解決它。
但是，如果我在需要移動磁碟時重新啟動，到目前為止我還沒有看到錯誤。第 20 個磁碟已重新添加，並正在以正確的速度重新建置（2TB 磁碟仍需要大約 36 小時），我正在觀看 ( tail -f) syslog，到目前為止一直很安靜。
需要幾天時間我才能自信地報告此事。但到目前為止，它看起來很有希望。這個問題的答案可能最終“不要在 Linux 上與 Rosewill RSV-S5 進行熱插拔”，祈禱吧。
答案1
雖然我仍然不太了解硬體周圍的低階架構或控制它的核心驅動程序，但這種情況下的「解決方案」似乎是不熱插拔驅動器。
因此，當在 Linux（也許在其他系統上也是如此，我不知道）上使用 Rosewill RSV-S5（或任何同類產品，我想）時，切勿熱插拔。如果syslog說已PORT_RST執行，請重新啟動以確保安全。
熱插拔乍看之下似乎有效。磁碟機上沒有安裝 FS，它只是一個裸分割區，硬體是透過磁碟機導軌等設定的，當您放入新磁碟機時，系統會識別它並為其分配一個可以與之互動的裝置。但syslog為了安全起見，請留意。