SanDisk SSD Plus：LinuxのパフォーマンスはWindowsの半分ですか？
ラップトップに2つのSSDがあります。
- Crucial MX300 725GB->/dev/sda
- SanDisk SSD Plus 240GB->/dev/sdb
LinuxおよびWindowsでのパフォーマンスは次のようになります。
Crucial MX300->両方のOSで同じ
Sudo hdparm -tT /dev/sda # Crucial
Timing cached reads: 13700 MB in 2.00 seconds = 6854.30 MB/sec
Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.58 MB/sec
SanDisk Plus-> Windowsでの高速化！
Sudo hdparm -tT /dev/sdb # SanDisk
Timing cached reads: 7668 MB in 2.00 seconds = 3834.92 MB/sec
Timing buffered disk reads: 798 MB in 3.00 seconds = 265.78 MB/sec # TOO LOW !!
LinuxでのSanDiskのシーケンシャル読み取りパフォーマンスは、Windowsでのパフォーマンスの約半分です！
私の質問はもちろんです：なぜそれを修正できますか？これは、SanDisk SSD PlusがSCSIドライブとして処理されているためですか？
Syslogから：
~$ grep SDSSD /var/log/syslog
systemd[1]: Found device SanDisk_SDSSDA240G
kernel: [ 2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133
kernel: [ 2.174689] scsi 1:0:0:0: Direct-Access ATA SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5
smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB
smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
LinuxでWindowsとほぼ同じパフォーマンスを持つCrucial MX300と比較して：
~$ grep MX300 /var/log/syslog
systemd[1]: Found device Crucial_CT750MX300SSD1
kernel: [ 1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1, M0CR050, max UDMA/133
smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB
smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
どんな助けも大歓迎です！
編集：
Linuxでhdparmが示す違いは非常に現実的です。 2つのドライブにそれぞれ2つの同一のディレクトリを作成し、各ディレクトリには約25Gbのファイル（36395ファイル）が含まれ、両方のディレクトリでまったく同じhashdeepチェックサム作成スクリプトを実行しました（スクリプトはすべてのファイルに対してmd5-checksumを作成するだけです）テストでは、すべてのチェックサムを1つのファイルに保存します）。結果は次のとおりです。
test-sandisk# time create-file-integrity-md5sums.sh .
real 1m49.000s
user 1m24.868s
sys 0m15.808s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m54.180s
user 1m4.628s
sys 0m11.640s
単一の7Gbファイルを使用した同じテスト：
test-sandisk# time create-file-integrity-md5sums.sh .
real 0m26.986s
user 0m19.168s
sys 0m3.232s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m17.285s
user 0m16.248s
sys 0m1.368s
編集2：
パーティションは「最適」にアライメントされ、/ sys/block/$ disk/queueの唯一の違いはdiscard_zeroes_data（Crucialで1、SanDiskで0）です。使用されるファイルシステムとマウントオプション：ext4と入力（rw、nosuid、nodev、relatime、data = ordered、uhelper = udisks2）
dmesg | grep -i sata | grep 'link up'
[ 1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
USBペンドライブとの比較
単純なUSBペンドライブは、しばらく使用すると徐々に遅くなります。そのようなドライブには破棄機能はありません（私が知る限り、私は高度で非常に高価なペンドライブについては話していません）。ドライブ全体を消去し、ゼロ（または内部的に1）で上書きすると、速度が再び回復します。私自身の経験から、これはサンディスクエクストリームペンドライブに当てはまることを知っています。これは、他のシンプルなUSBペンドライブと比べて、新品のときは高速です。
そのため、Sandisk SSDのパフォーマンス低下の原因は、破棄メソッド（またはその欠落メソッド）にあると予想できます。 @Starmanの答えは、あなたの問題を解決するための貴重な情報を追加すると思います。
あなたはできる
システムを一晩アイドル状態にしておき、アイドル時間を使用して破棄すべきものを破棄しているかどうかを確認します。運がなければ、できます
ドライブの空き領域を消去して、パフォーマンスが向上するかどうかを確認します。
linuxのマウントオプションまたはSSDの設定を見つけて、パフォーマンスを改善してください。
道具
zerofreeは、extファイルシステム用の効率的なツールです。このリンクをご覧ください。それ以外の場合（チェックとダブルチェックですべてが正しい場合）、
ddを使用して、ゼロを含む巨大なファイルblankを作成し、後で消去できます（遅くなりますが、すべてのファイルシステムで動作します）。ライブUSBドライブなど、別のドライブから起動します
cd <mountpoint-of-the-target-partition> # for example: cd /mnt Sudo dd if=/dev/zero of=blank bs=4096ドライブがいっぱいになったため停止するまで実行し、その後ファイル
blankを削除します。これは、blankという名前の便利なファイルが既に存在しないことを前提としています。Sudo rm blank警告：
ddは強力だが危険なツールなので、貴重なデータを破壊しないことを確認し、再確認してください。この場合、安全にプレイするには、接続されたドライブ上の貴重なものをすべてバックアップして別の場所（たとえば、後で切断される外部ドライブ）にバックアップします。
デバイス全体を拭きます
USBペンドライブの私の方法は、（部分的に満たされたパーティション内のファイル間の空きスペースだけでなく）デバイス全体を消去することです。これはペンドライブの最も効率的な方法だと思いますが、デバイス全体を消去せずにSSDで効率的に動作する破棄設定が必要だと思います。とにかく、テストしたい場合は試してみてください。その後、新しいパーティションテーブルとext4パーティションを作成します。このリンクをご覧ください
@sudodusの素晴らしい投稿に応えてコメントを1つ追加したかったのですが、現在はコメントを許可されていない4担当者がまだいるので、ここに貼り付けます。
物事をアイドル状態のままにすることに関しては-私が取り組んだeMMCテクノロジー（これも同様ですが、あなたのものと同一ではないはずです）は、システム設計者がコアの電力を削減し、残すだけであると想定しなければならなかったため、これは機能しませんでしたIO電力が生きています。
実際には省電力を調整するスリープモードがありますが、eMMCベンダーは、ただ時間の途中でバックグラウンド操作を開始するのではなく、コマンドを受け入れる間にのみこれらのクリーンアップタイプの操作を実行したいと言っていたことを覚えていますステータス（結果）を返す前に送信します。
SSDが異なる可能性があります。具体的には、アイドル時間中に、NANDフラッシュバックエンドにコマンドを送信し、その中のデータブロックのクリーンアップと再編成を行うコントローラーがあります。しかし、私の経験からすると、必ずしもそうなるとは思わないでしょう。
これは十分な答えではないかもしれませんが、私は新しくて「コメント」することができず、それが役立つ場合にあなたと共有したかったです：
以前はSSDと同様のハードウェア基盤であるeMMCフラッシュメモリを使用していました。 discard_zeroes_dataは問題のようです。消去、特にトリムと呼ばれる非常に遅い機能がありました（消去に似ていますが、パフォーマンスに必要なはるかに大きな消去グループブロックではなく、4kBの読み取りブロックベースです。後でデータを消去しない「破棄」機能が導入されました。すべてゼロ（実際にはすべて1ですが、便宜上、逆になっています）が、データの状態を「気にしない」に変更しただけです。
したがって、4kBのデータで破棄を行った場合、消去を行わなかったため高速になりましたが、ファームウェアにはデータが不要になったことを知らせ、テーブル内のその物理領域を追跡しました。これにより、ガベージコレクションタイプのメカニズムは、後で十分な近隣を消去し、必要に応じて必要なデータを別のエリアにコピーしてから、高価な「消去「バックグラウンドでの操作。
TBH最初は破棄が無効になりました。破棄状態であまりにも多くのデータが残っていて、物理的な消去が行われなかった場合にパフォーマンスの問題が発生したためです。
そのため、「discard_zeros_data」が何を意味するのか正確に言うことはできませんが、もし私なら、間違いなく反対の状態に変更して、何が起こるか見てみます。 「件名動詞オブジェクト」のように表示される場合、セキュリティ機能である可能性があり、小さなデータでも強制的に消去するのに時間がかかるため（高価）、あなたが思った後に誰かがあなたの古いファイルを取り戻すことができませんそれらを削除しました。これを「ゼロ」に設定すると、実際に読むとパフォーマンスが向上すると思いますが、逆の場合があります。
また、特別なSSDツールを使用する場合でも、完全なフォーマットを使用する場合でも、可能な限り最大の強制「消去」を実行し、この消去直後にパフォーマンスが向上するかどうかを確認します。これにより、少なくとも問題に関する情報が得られます。
ファイルシステムの種類も間違いなく重要ですが、これは2回の実験で一定だと思います。