私はSeagateディスク(ST5000LM000 - SMRであることに留意)を持っていますが、書き込み作業量が多い場合I/O利用度は100%になり、スループットは基本的に0になります。ドライバを使用してディスクをmpt3sasSASコントローラに接続します（ディスクはscsiデバイスとして表示されます）。スケジューラを変更してnoop、ncqを1に設定し、デバイスタイムアウトを1時間に増やしました。まったく異なるディスクコントローラ（ドライバを使用megaraid）を試してみましたが、何も変わりませんでした。各ドライブにはXFSパーティションがあります。
役に立つ唯一の方法は、ファイルを作成するスクリプトの並行性を減らすことで、ディスクI / Oが雪玉効果によって問題が発生するほど遅れないようにすることです。
同時ディスク操作を防ぐ必要があると思いますecho 1 > /sys/block/sdl/device/queue_depthが、通常約150の作業が進行中であるようですcat /sys/block/sdl/stat。
これは大きな問題です。この問題が発生し始めたときにロードスクリプトを終了しないと、最終的にI / O操作がタイムアウトするためです。ディスクが切断されたこれにより、プロセスがひどい状態に陥り、Dデータが破損することがよくあります。
これらの悪い状態に陥ることを防ぐために変更できるカーネル設定はありますか？ 十分に早くシャットダウンすると、I / O操作がタイムアウトし、ディスクが切断される前に常にキャプチャされる可能性があるため、何かをする必要があるようです。
kern.log実際にディスクが切断された時点から
[401217.833235] sd 0:0:6:0: device_block, handle(0x0010)
[401218.583675] mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03)
[401218.833518] sd 0:0:6:0: device_unblock and setting to running, handle(0x0010)
[401222.584105] sd 0:0:6:0: device_block, handle(0x0010)
[401230.581727] sd 0:0:6:0: device_unblock and setting to running, handle(0x0010)
[401230.586627] scsi_io_completion: 6 callbacks suppressed
[401230.586641] sd 0:0:6:0: [sdg] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[401230.586656] sd 0:0:6:0: [sdg] tag#0 CDB: Read(16) 88 00 00 00 00 01 3b e5 74 18 00 00 02 00 00 00
[401230.586661] XFS (sdg): metadata I/O error: block 0x800007b8 ("xfs_trans_read_buf_map") error 5 numblks 32
[401230.586670] XFS (sdg): xfs_imap_to_bp: xfs_trans_read_buf() returned error -5.
[401230.597537] blk_update_request: 6 callbacks suppressed
[401230.597540] blk_update_request: I/O error, dev sdg, sector 5299860504
ディスク帯域幅は本質的にゼロに低下します。
平均I/O要求時間の急増
ディスクI / Oは100％の使用率を維持します。
実行中のI/O要求は約150個のままです。
（ちなみに、上記の画像では、書き込みスループットが大幅に低下したときにロードスクリプトをキャンセルしたため、最終的に回復しました。）
ディストリビューション/カーネル
$ lsb_release -d
Description: Ubuntu 16.04.6 LTS
$ uname -r
4.15.0-62-generic
fdisk -l
Disk /dev/sdl: 4.6 TiB, 5000981078016 bytes, 9767541168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
xfs_info
meta-data=/dev/sdl isize=512 agcount=5, agsize=268435455 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0
data = bsize=4096 blocks=1220942646, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
答え1
次のカーネルパラメータを変更しましたが、高書き込み負荷でSMRディスクの接続が切断されなくなりました。場合によっては、過剰なI / O（たとえば、1桁のMB /秒の書き込み速度）は書き込みパフォーマンスを非常に遅くする可能性がありますが、少なくともディスク接続が失われることはありません。
DEVICE=sdX # insert your device name here
echo 3600 > /sys/block/$DEVICE/device/timeout
echo 3600 > /sys/block/$DEVICE/device/eh_timeout
echo noop > /sys/block/$DEVICE/queue/scheduler
echo 1 > /sys/block/$DEVICE/device/queue_depth
echo 4 > /sys/block/$DEVICE/queue/nr_requests
それぞれを個別にテストしていないので、それぞれを設定する必要があるかどうかはわかりませんが、この組み合わせは私にとっては効果的でした。
答え2
SMRドライブでXFSやext4を使用するのと比較して、F2FSを使用するのは良い経験でした。私のext4はSMRドライブで前述したのと同様の動作を示しているので、LinuxでSMRソリューションを調べる必要があります。また、お客様が説明するタイムアウトの問題が発生しました。私もUbuntuを使用していますが、最新のUbuntu 18.04.3 LTSバージョンを使用しています。
まず、ランダムな読み取り/書き込み操作が多いサーバーにはSMRドライブをお勧めしません。 SMRの使用を避けたいユースケースの例には、読み取り/書き込みスループットの高いデータベースおよびNASアプリケーションがあります。私のユースケースはNASの外部バックアップですが、これは時間がかかりません。
最初にすべきことは、F2FSファイルシステムを取得することです。これは18.04で非常に簡単です。
sudo apt install f2fs-tools
gpartedSMRドライブのすべてのパーティションを削除してから、ドライブ全体にわたるgpartedF2FSパーティションを作成するために使用します。
マイドライブ（Toshiba）は、MS-Windowsオペレーティングシステムコンピュータで使用するために2つのパーティションに事前フォーマットされています。最初のパーティションを小さくすると、どのファイルシステムをインストールしても書き込み速度がひどいです。私は最初のパーティションがドライブのSMR以外の部分がログや他のメタデータに割り当てられる場所であると強く疑っています。私の経験では、作成されたファイルシステムがこの領域にアクセスして利点を得ることが非常に重要です。
残念ながら、gpartedには、ブロックパーティションのSMRドライブに適したファイルシステムを適切に作成するためのオプションを設定できる場所がないようです。パーティション識別情報を記録した後、gpartedmkfsコマンドを終了して手動で実行しましたが、今回は次のような魔法が追加されました。
sudo mkfs.f2fs -fm /dev/XXXX
XXXX以前に識別したパーティションはどこにありますかgparted？ -m オプションは、F2FS に SMR ドライブの遮断領域機能を使用するよう指示するため、重要です。それがなければ、私の経験によると、あなたは屋根の地獄で苦しむでしょう。
これが完了してインストールされると、ドライブへの書き込みは非常に一貫しています。私の書き込み速度はほとんど117 MB / sから105 MB / sの間です。時々、数秒間書き込み速度が70-80 MB / sに低下した。
私はSMRドライブがターゲットヘルペスが重なるドライブ領域を書き換えて追いつく必要があると思います。幸いなことに、これは頻繁に起こりません。しかし、（まだ）ハードドライブの空き容量を半分も利用できないことは認めています。これが発生すると、shingled書き込みがより頻繁に発生し、バックアップに時間がかかることが予想されます。しかし、これはプラッタのタイル化された領域を避けるのに非常に効果的であり、速度が遅くなる例の多くを見つけることが困難です。また、デバイスのカプセル化されていない領域を活用してメタデータ（ログ）を保存するように見えます。
また、読み取りが完了してコマンドプロンプトが返された後、F2FSが残りのデータをフラッシュするのに約10秒かかったことも確認しました。データの損失を防ぐために、この期間中にデバイスを取り外したりプラグを抜いたりしないことが重要です。シェルスクリプトを使用している場合は、この点に注意してください。
私はF2FSを使った私の書き込み速度がxfsを使った書き込み速度よりはるかに高いことに同意するでしょう。また、これを達成するために時間制限を変更する必要もありませんでした。