新しいハードドライブでの非特定のカーネルエラー、ドライブに障害が発生していますか？
RAID5アレイを備えたサーバーでCentOS7.7.1908を実行しています（mdadmソフトウェアRAIDを使用）。アレイは4台の4 TBドライブで構成されています。最近、一部のドライブを新しいWD Redドライブに交換しました。ある朝目が覚めるまで、すべてが1週間強で問題ありませんでした。 「失敗」イベント。新しいドライブの1つ（/dev/sda）が失敗としてマークされ、アレイからドロップされたようです。
短いSMARTセルフテストを実行し、ドライブは正常にチェックアウトされました。ドライブのSMARTログに他のエラーは記録されなかったので、追加しましたアレイは正常に再同期され、すべてが正常に表示されますが、失敗イベントを引き起こしたものは何もないため、ドライブに問題があるのではないかと心配しています。
以下は、ドライブがアレイから「故障」したときのsyslogメッセージです。
Apr 9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 9 03:34:11 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 9 03:34:11 server kernel: blk_update_request: I/O error, dev sda, sector 2056
Apr 9 03:34:11 server kernel: md: super_written gets error=-5, uptodate=0
Apr 9 03:34:11 server kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.
Apr 9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 9 03:38:50 server kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 9 03:38:50 server kernel: blk_update_request: I/O error, dev sda, sector 0
Apr 9 03:38:51 server kernel: mpt2sas_cm0: log_info(0x31110610): originator(PL), code(0x11), sub_code(0x0610)
エラーには「追加のセンス情報がない」と記載されているため、何が起こったのかを正確に把握することは困難です。ただし、再同期が完了した後、ドライブで拡張SMARTテストを実行することにしました。昨日の午後に開始し、順調に進んでいました...今朝目が覚めるまで。
一晩中「残りテストの10％」になっているらしいので、何かがうまく機能していないと思います。また、このドライブのSMART情報は、「拡張セルフテストルーチンの推奨ポーリング時間」が497分であるのに対し、アレイ内の他のドライブの時間は497分であることを示しています。メーカーとモデルは同じです-約205分です。
だから...おそらくこれはエラーがある欠陥のあるドライブですSMARTは記録されませんか？または何か他に起こっている可能性がありますか？誰かが以前にこのようなものを見たことがありますか？何か助けがありますか？感謝します。ありがとう！
更新：詳細情報
要求に応じて、問題のドライブのsmartctlの出力は次のとおりです
[user@localhost]~% Sudo smartctl -a /dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1062.18.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: WDC WD40EFAX-68JH4N0
Serial Number: WD-XXXXXXXXXXXX
LU WWN Device Id: 5 0014ee 2bce22f9d
Firmware Version: 82.00A82
User Capacity: 4,000,787,030,016 bytes [4.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Apr 10 11:02:15 2020 CDT
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: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 241) Self-test routine in progress...
10% of test remaining.
Total time to complete Offline
data collection: (23324) 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: ( 497) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x3039) 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 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 100 253 021 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 4
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 100 100 000 Old_age Always - 205
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 - 4
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 2
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 19
194 Temperature_Celsius 0x0022 114 107 000 Old_age Always - 33
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 177 -
# 2 Extended offline Interrupted (Host reset) 10% 108 -
# 3 Short offline Completed without error 00% 0 -
# 4 Conveyance offline Completed without error 00% 0 -
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.
更新：さらに詳しい情報
@dirktからの次の提案に従って、元のsyslogエラーに記載されているセクターから読み取ろうとしました。
[user@localhost]~% Sudo dd bs=512 if=/dev/sda1 of=./sector0-sda1.txt skip=0 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00244528 s, 209 kB/s
[user@localhost]~% Sudo dd bs=512 if=/dev/sda1 of=./sector2056-sda1.txt skip=2056 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00281374 s, 182 kB/s
これは私がよく知っていることではありませんが、これは読み取りが成功したことを意味すると思いますか？セクター0のファイルは空であり、セクター2056のファイルには意味不明なものが含まれています。私は彼らに手紙を書くことを試みるべきですか？ 編集：おそらく追加する必要があります-SMART情報は読み取り後も同じままです。エラーは記録されず、拡張テストはまだ「残り10％」です。
アップデート＃3
私はそれらのセクターを読むことができるように見えるので、それらは大丈夫のようです。 （上記のように）それらを読んだ後、SMARTログ：
[user@localhost]~% Sudo smartctl -a /dev/sda
...
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 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 100 253 021 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 4
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 100 100 000 Old_age Always - 252
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 - 4
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 2
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 19
194 Temperature_Celsius 0x0022 111 107 000 Old_age Always - 36
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
そこで、ドライブをアレイに追加し直しました。再同期は成功しましたが、エラーはまだ再発していません。だから多分それは大丈夫ですか？
[user@localhost]~% cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdb1[7] sdc1[5] sdd1[4] sda1[6]
11721047040 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
私が気付いた新しいことの1つは、拡張セルフテストに関する以下のメモに従って、smartctl -t select,0-max /dev/sdXを指定して選択的なセルフテストを実行してみたことです。以下の回避策によると、これは長いテストを模倣する必要がありますが、より詳細な進行状況インジケーターを提供します。長いテストがすべてのドライブで数日間残っている10％でスタックしたため、私はすべてのドライブでこの選択テストを実行しました。アレイ内の3つの「良好な」ドライブの場合、選択テストは妥当な時間内（数時間、ただし1日未満）にエラーなしで完了しました。 「疑わしい」ドライブ（/dev/sda）での選択テストには、はるかに長い時間がかかります。以前と同じように10％残っていると表示されますが、進行状況インジケーターの方が便利です。
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 7814037167 Self_test_in_progress [10% left] (5010947864-5011013399)
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
それは約のために実行されています。この時点で12時間。非常にゆっくりと進んでいますが（特に他のドライブと比較して）、まだ進行しているようです。終了したら更新を投稿します（終了した場合）...編集：選択的セルフテストが最終的に終了し、エラーなしで完了しました。だから私はそれがすべてが順調であることを意味すると思いますか？
アップデート＃4：リターン
この1週間、すべてが正常に機能していました。残念ながら、今日の午後、同じドライブが再びアレイから脱落しました。同じエラーがsyslogに表示されました。
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 14 18:07:38 xenon kernel: blk_update_request: I/O error, dev sda, sector 2056
Apr 14 18:07:38 xenon kernel: md: super_written gets error=-5, uptodate=0
Apr 14 18:07:38 xenon kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:08:50 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
Apr 14 18:08:50 xenon kernel: blk_update_request: I/O error, dev sda, sector 0
Apr 14 18:08:51 xenon kernel: mpt2sas_cm0: log_info(0x31110610): originator(PL), code(0x11), sub_code(0x0610)
これらのエラーの後、mdadmから通知を受け取りました。
[user@localhost]/var/log# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md127 : active raid5 sdb1[7] sdc1[5] sdd1[4] sda1[6](F)
11721047040 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [_UUU]
unused devices: <none>
/dev/sdaで選択的なSMARTテストを開始しましたが、前のテストのいずれも問題がないため、オプトミスティックではありません。ありますかこれが不良ドライブなのか、それともドライブコントローラが不良なのかを判断する方法はありますか？どちらの場合も同じドライブがドロップしたので、ドライブだと思う傾向がありますが、誰かがログのエラーをデコードする方法を知っていますか？より多くの情報を提供して幸せです。ありがとう！
アップデート＃5：佐賀は続く
物事をフォローしている人のために、ここに最新のものがあります：
- 古いエンクロージャーを持っていたので、元の2 TBドライブをその中に入れて、新しい「スペア」アレイをすばやく作成しました。
- 4 TBドライブアレイの内容をスペアアレイにコピーしました。
- 元のアレイを削除し、4台のTBドライブを使用して新しいRAID10アレイを作成しました（さまざまな検索に基づくと、大型ドライブ、特に4台以上のRAID5は実際には提供されていないようです）優れたパフォーマンスまたは冗長性）。
- 新しいアレイは正常に初期化されました。元のデータを2 TBドライブスペアアレイから新しい4 TBドライブRAID10アレイにコピーしました。
- 以下の@dirkt（すごい、ところで）との話し合いに基づいて、
echo 1 > /sys/block/sdX/device/queue_depthを介して各4TBドライブのNCQを無効にしました。これは、アレイの複雑さ/並列処理を減らすための取り組みであり、NCQが実際にはRAIDパフォーマンスに悪影響を与える可能性があることを示す議論がいくつかあるためです。この一時的な修正を使用してアレイを実行し、問題が解決するかどうかを確認します。 - ArsTechnicaコメントボードのMikeUchimaからのヒント（ 元の投稿はこちら ）に基づいて、アレイのファイルシステムに
noatimeマウントオプションも設定しました（デフォルトでは設定されていません）。 ext4ファイルシステム）。コメントボードの説明によると、最終アクセス時間を更新すると、ドライブのSMRロジックが圧倒され、最終的にドライブがドロップされる可能性があります。 - 「障害のある」ドライブ（または別のドライブ）がアレイから再び脱落した場合は、更新を投稿します。
さらに、多くのメディアが、Western Digitalを含む主要なハードドライブメーカーによるいくつかの欺瞞的なマーケティング慣行について報告し始めています（例 ここにリンクされています ）。 SMRがNASおよびRAID構成（NAS $ ===）で問題を引き起こすことが知られているにもかかわらず、RedドライブのいくつかのモデルでShingled Magnetic Recording（SMR）をそのようにラベル付けまたは宣伝せずに使用しているようです。皮肉なことに、SMRの問題のいくつかは WD自身の資料でここに記載されています 、ドライブ管理のSMRは並列操作には悪いと指摘しています... RAIDのように）これは明らかに問題です。赤いドライブはNASおよびRAIDの目的で）特別に販売されています。
4のモデルTB私が購入したドライブはSMRを使用するドライブのモデルの1つであると思われます（モデルWD40EFAX）。ニュース記事によると、256 MBのキャッシュを備えたEFAXモデル（私のように） ）はSMRを使用する可能性があります。hdparm -Iを使用すると、ドライブがTRIMをサポートしていることがわかります。これは、ドライブがSMRを使用していることを示すもう1つの指標です。
[user@localhost]~% Sudo hdparm -I /dev/sda
/dev/sda:
ATA device, with non-removable media
Model Number: WDC WD40EFAX-68JH4N0
...
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, with device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* Data Set Management TRIM supported (limit 10 blocks)
* Deterministic read ZEROs after TRIM
私は今、私の問題の原因がSMRである可能性があることを疑っており、神経質になっています。これは明らかに修正できるものではありません。 Western Digitalにサポートチケットを提出し、このすべての情報を提供し、「障害のある」ドライブをSMRではなくCMRを使用するバージョン（おそらくWD40EFRXモデルはCMRを使用）と交換するかどうかを尋ねました。どちらの方法でもここに更新を投稿するので、もう1つのケーススタディがあります。
終わりのない拡張テストについてのメモ
一部のグーグル検索は、拡張/長いSMARTテストが終了しない（90％完了/ 10％残り）が明らかに一般的な問題であることを示しているようです-良いドライブでも。私は走り始めました私のアレイの他のドライブの1つで長いテストを行い、それもかなり長い間10％のままになっています。これが発生する理由については多くの理論がありますが、修正についてはあまりありません。可能な回避策を見つけました。 （下のリンク）私が試してみますが、そうでなければ、これはイライラするバグかもしれません。
ちょっとした閉鎖を提供したかっただけです。 SMRとCMRの問題は現在 一般的な知識 であるため、この問題（上記のファームウェアの問題と組み合わせて）が問題の原因である可能性が高いと推測しています。私はWDに連絡し、ドライブを同等のEFRXモデルに置き換えるかどうか尋ねました（このモデルはCMRを使用しているため）。ドライブはまだ小売業者の返品ポリシーウィンドウ内にあったので、ドライブを返品するよう提案されました。手元に交換しないと返品できなかったため（データが含まれていたため）、交換用として4台の新品のWD Red Pro4TBドライブを注文しました。私はWDにもう一度チャンスを与えると思いました、そして確かにプロドライブは同じ問題を抱えていません（これは以前WDがどのドライブに関する詳細をリリースしたかについての詳細に注意してください各テクノロジーを使用）...
新しいドライブを受け取り、すぐにSMARTツールとbadblocksを使用してテストしました。すべてのドライブが多数のエラーを返しました。すべての単一のドライブ。これは、出荷中の乱暴な取り扱いが原因である可能性があります。 、しかし関係なく-私は今4つのmoreドライブを返品しました。これらを不良品として小売店に返品しましたが、この時点で私は使い果たそうとしていました元のEFAXドライブのリターンウィンドウ。新しいドライブのセットを取得してテストし、アレイにスワップしてから、残りのリターンウィンドウ内で元のドライブを消去することはできません。
元のWDチケットに戻って状況を説明し、EFRXバージョンで元のドライブをRMAするように再度要求しました。そして...彼らは同意しました！私は少し驚いたが、サポート担当者は私のEFAXドライブをRMAすることに同意した。私は実際に4台のEFAXドライブを持っていることを彼らに伝え、EFRXバージョンで4台すべてをRMAできるかどうか尋ねたところ、彼らもそれに同意しました。最後に、事前のRMAをリクエストして、新しいドライブを今すぐ受け取り、すべてを交換したら古いドライブを返送できるようにしました。彼らもこれに同意した。
その後、サガのサポート担当者から連絡があり、EFRXモデルは現在倉庫に在庫がないが、まもなく利用可能になるとのことでした。そのため、彼らは私に待つか、EFRXドライブの代わりにRedProドライブを入手するかの選択肢を与えてくれました。 Red Proバージョンを入手できてうれしく、先週受け取りました。これらのドライブはすべてSMARTツールとbadblocksのテストに合格し、それらをアレイに正常にスワップしました。新しいアレイはそれほど長い間稼働していませんが、そこにあることを望んでいます。それ以上の問題はないので、WDが（最終的に）物事を正しくしようとしたことを嬉しく思います。もちろん、最初の行動を許すことはありませんが、少なくとも彼らはいくつかの批判に耳を傾けているようです。
部分的な答え：
しかし、誰かがログのエラーをデコードする方法を知っていますか？
_Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Sense Key : Aborted Command [current]
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 Add. Sense: No additional sense information
Apr 14 18:07:38 xenon kernel: sd 0:0:0:0: [sda] tag#0 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
_SCSIコマンドSynchronize Cache(10)が失敗し、デバイスから追加情報が報告されませんでした。 tagは、おそらくUASプロトコル（USB接続SCSI）を使用していることを示しているため、複数のコマンドを同時に実行できます。
_Apr 14 18:07:38 xenon kernel: blk_update_request: I/O error, dev sda, sector 2056
_これは、ブロック2056を更新しようとしたときに発生しました。
_Apr 14 18:07:38 xenon kernel: md: super_written gets error=-5, uptodate=0
_これはmdレイヤーから呼び出されました。
_Apr 14 18:07:38 xenon kernel: md/raid:md127: Disk failure on sda1, disabling device.#012md/raid:md127: Operation continuing on 3 devices.
_したがって、mdレイヤーはそのハードディスクをキックアウトすることを決定します。
これが不良ドライブなのか、それともドライブコントローラーが不良なのかを判断する方法はありますか？
言うのは本当に難しいです。 （a）時々発生し、（b）同様のセクターで発生し（つまり、mdレイヤーが同様のことを行う場合）、（c）UASが有効になっている場合、現在の推測では次のようになります。コマンドを並行して処理するときに発生するドライバー/ファームウェアのバグ、および開発者が予期していなかった奇妙な状態が表示されます。
SMARTの値は適切であり、影響を受けるセクターを読み取ることができるため、物理的にドライブは問題ないはずです。
したがって、次に私がしたいのは、ソフトウェアの相互作用の複雑さを軽減し、それが役立つかどうかを確認することです。そのため、そのドライブ（google）のUASを無効にし、しばらく実行して、エラーが引き続き発生するかどうかを確認します。 UASを無効にすると、パフォーマンスが少し低下する可能性があります。
smartctl-aではなくsmartctl-xを使用する
ドライブがそのように内部的にログに記録しているエラーが表示されます-IDNFのエラーはすべての可能性があります。
これはWD ファームウェアエラーであり、現在確認を拒否しており、ドライブがCMRユニットを装ったDM-SMRであるという問題の上です。