I / O書き込みストレステストの競合は、必ずしもSSDハードウェアエラーを意味しますか?

I / O書き込みストレステストの競合は、必ずしもSSDハードウェアエラーを意味しますか?

概要

過去2年間、SSDを読み取り専用にするファイルシステムエラーのため、デスクトップコンピュータが断続的にクラッシュしました。何も起こらずに1週間以上実行することができ、特定の日に複数回競合する可能性があります。バックアップとリカバリの間に書き込み操作が多いか、起動直後に頻繁に発生するように見えますが、他の場合にも発生する可能性があります。断続的な衝突問題を解決したと思ったこともありましたが、しばらくしてまたそういうことが起こりました。

編集:これらのシャットダウンはUEFIブートエントリを破損し、ブートするために複数回電源を入れ直す必要があることがよくあります。

また、ファイルをUSBドライブに正しくコピーできませんでしたが、$ dd以下のようにRAM構成を変更した後に問題が解決したようです。

これは、さまざまなディストリビューション(すべてDebianベース)と複数のファイルシステム(ext4とbtrfs)の複数のインストールで発生します。

私のデータは外部ドライブにバックアップされ、最も重要な部分は同期を介して他のデバイスに保存されます。 SSDはいつでも故障する可能性があることを知っています。


仕様と構成

CPU: AMDライゼン9 3900x

SSD:1TBサムスン970 EVOプラス

RAM: Crucial Ballistix 3200MHz(16GB x 2) BL2K16G32C16U4B

マザーボード:ASRock B550ファントムITX

現在のリリース: KDE Neon


私が試したこと

数ヶ月前にmemtester(Linux上で実行され、独立して起動しない)を使用してRAMをテストし、おそらく1年前にはより広範囲にテストしました。このRAMで行ったテストでは、メモリエラーは発生しませんでした。

私は私のRAMに1.35Vの基本工場オーバークロック電圧が必要であることを発見しました。 BIOSでこの問題を解決しました。これはUSBドライブとSDカードへの誤った書き込みを解決するのに役立ちますが、断続的なクラッシュを解決するわけではありません。以前に他の設定を読み、調整したことがありますが、現在はすべてが工場出荷時のデフォルトに設定されているようです。

約1年前にUEFIファームウェアをアップデートしました。 UEFIファームウェアを最新バージョンにアップデートしました。

SSDのファームウェアアップグレードを試しましたが、そのバージョンでサポートされている最新バージョンのようです。

上記のように、起動パラメータのASPM設定を調整しました。これ同様の症状で問題が発生します。

smartmontools - > smartctlを使用してSSDを確認しました。何も普通ではないようだった。

    === START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        56 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    19,717,312 [10.0 TB]
Data Units Written:                 39,276,405 [20.1 TB]
Host Read Commands:                 117,854,095
Host Write Commands:                1,047,333,000
Controller Busy Time:               1,195
Power Cycles:                       702
Power On Hours:                     1,261
Unsafe Shutdowns:                   30
Media and Data Integrity Errors:    0
Error Information Log Entries:      3,591
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               56 Celsius
Temperature Sensor 2:               55 Celsius

journalctl | egrep 'kernel.*nvme'編集:これは、シャットダウンと再起動をトリガーした直後にdmesgに出力される関連行です$ stress-ng --hdd $(nproc)

Jul 03 23:38:51 $HOSTNAME kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-51-generic root=UUID=e624d68e-7ffe-4bdb-98e3-a349ac9cc3e0 ro quiet splash nvme_core.default_ps_max_latency_us=0 pcie_aspm=off vt.handoff=7
Jul 03 23:38:51 $HOSTNAME kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.13.0-51-generic root=UUID=e624d68e-7ffe-4bdb-98e3-a349ac9cc3e0 ro quiet splash nvme_core.default_ps_max_latency_us=0 pcie_aspm=off vt.handoff=7
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: pci function 0000:01:00.0
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: missing or invalid SUBNQN field.
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: Shutdown timeout set to 8 seconds
Jul 03 23:38:51 $HOSTNAME kernel: nvme nvme0: 32/0/0 default/read/poll queues
Jul 03 23:38:51 $HOSTNAME kernel:  nvme0n1: p1 p2 p3 p4 p5
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p3): re-mounted. Opts: (null). Quota mode: none.
Jul 03 23:38:51 $HOSTNAME kernel: Adding 67108860k swap on /dev/nvme0n1p2.  Priority:-2 extents:1 across:67108860k SSFS
Jul 03 23:38:51 $HOSTNAME kernel: EXT4-fs (nvme0n1p4): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
Jul 03 23:38:52 $HOSTNAME kernel: EXT4-fs (nvme0n1p5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.

私の発見

ついに衝突が発生する原因を発見しました。

$ stress-ng --hdd $(nproc)

$ iotop -oディスクが読み取り専用状態に強制され、10秒以内にすべてのI / Oアクティビティが停止し、systemd-journaldまたは他のディスクに書き込めない状態が原因で20秒以内にシャットダウンすることを示します。

~によると手動ストレス-ngの場合、一時ファイルを書き込み、読み取り、削除します。その他源泉write() および unlink() 呼び出しを使用すると主張します。

次のような他のオプション

$ stress-ng --io $(nproc)
$ stress-ng --cpu $(nproc)
$ stress-ng --vm $(nproc)
$ stress-ng --iomix $(nproc)

何の問題も起こらないようです。


質問

私のコンピュータを継続的にクラッシュさせるストレステスト$ stress-ng --hdd $(nproc)のユニークな機能は、SSDハードウェアが原因であることを意味しますか?

SSDは致命的なエラーとして知られていることを読んだので、問題が実際にSSDにあるかどうかはわかりません。私は問題の本質をよりよく理解することに非常に興味があるので、関連文書へのリンクやそのトピックについて私が提供できる知恵の言葉をいただきありがとうございます。

ベストアンサー1

おすすめ記事