web-dev-qa-db-ja.com

ディスクが切断され、SMRディスクでデータが破損する原因となるディスクI / Oタイムアウトを防ぐ方法は？

私はこれらのシーゲイトディスク（ST5000LM000-SM​​Rであることに注意してください）を持っています。これらを重い書き込みワークロードに置くと、I/O使用率は100％になり、スループットは基本的にゼロになります。ディスクは、mpt3sasドライバーを使用するSASコントローラーに接続されています（ディスクはscsiデバイスとして表示されます）。noopスケジューラーに変更してみました。 ncqを1に、デバイスのタイムアウトを1時間に増やします。何も変更しない完全に異なるディスクコントローラー（megaraidドライバーを使用）を試しました。各ドライブには単一のXFSパーティションがあります。

役立つと思われる唯一のことは、ファイルを書き出すスクリプトの同時実行性を減らして、ディスクI/Oがこれまで遅れることがなく、Snowball効果が物事を停止させることです。

echo 1 > /sys/block/sdl/device/queue_depthは同時ディスク操作を防ぐべきだと思いましたが、通常、cat /sys/block/sdl/statから約150の操作が実行中です。

これが発生し始めたときにロードスクリプトを強制終了しないと、最終的に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

ディスク帯域幅は基本的にゼロに低下します disk bandwidth basically drops to zero 平均I/Oリクエスト時間は急増 average i/o request time skyrockets ディスクI/Oは100％の使用率のままです disk i/o stays at 100% utilization 実行中のI/O要求は約150のままです in-flight i/o requests stays around 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
linuxhard-diskio
2
gregjhogan

以下のカーネルパラメータを変更すると、書き込み負荷が大きい場合に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

私はそれぞれを個別にテストしなかったので、すべてを設定する必要があるかどうかはわかりませんが、この組み合わせでうまくいきます。

0
gregjhogan

SMRドライブでXFSやext4とは対照的に、F2FSを使用して良い経験をしました。私のext4は、SMRドライブで上記と同様の動作を示し、LinuxでのSMRソリューションの調査を余儀なくされました。あなたが説明するタイムアウトの問題も経験しました。私もUbuntuを使用していますが、それ以降のUbuntu 18.04.3LTSバージョンです。

まず、ランダムR/Wオペレーションが高いサーバーにはSMRドライブを推奨しません。 SMRの使用を避けたいユースケースの例は、データベースとNAS高r/wスループットのアプリケーションです。私のユースケースはNASの外部バックアップですが、それで問題ありません。タイムクリティカルではなく、ほとんどが順次です。

最初に行うことは、F2FSファイルシステムを取得することです。これは18.04では次のように簡単です。

Sudo apt install f2fs-tools

gpartedを使用して、SMRドライブからすべてのパーティションを削除してから、gpartedを使用して、ドライブ全体にまたがるF2FSパーティションを作成します。

私のドライブ（Toshiba）は、MS-WindowsOSマシンで使用するために2つのパーティションで事前にフォーマットされています。小さい最初のパーティションを保持した場合、インストールしたファイルシステムに関係なく、書き込み速度はひどいものでした。最初のパーティションは、ドライブの非SMR部分が、そのジャーナルやその他のメタデータに使用するために割り当てられている場所だと思います。私の経験では、作成されたファイルシステムがこの領域にアクセスしてその利点を得ることが非常に重要であることが示されています。

残念ながら、gpartedには、ブロックゾーンSMRドライブに適したファイルシステムを適切に作成するためのオプションを設定できる場所がないようです。パーティション識別情報をメモした後、gpartedを終了し、手動でmkfsコマンドを実行しました。今回は、マジックソースを追加しました。

Sudo mkfs.f2fs -fm /dev/XXXX

ここで、XXXXは、以前にgpartedで識別したパーティションです。この-mオプションは、SMRドライブのブロックゾーン機能を使用するようにF2FSに指示するため、非常に重要です。それがなければ、私の経験はあなたが鉄片地獄で苦しむことを示しています。

それを行った後（そしてそれをマウントした後）、ドライブへの書き込みはかなり一貫していました。私は主に117MB /秒から105MB /秒の間の書き込み速度を取得します。非常にまれに数秒間、書き込み速度が70〜80MB /秒に低下します。

SMRドライブがシングルオーバーラップのあるドライブの領域を再書き込みすることでキャッチアップを再生する必要があるのは、ディップが原因だと思います。幸いなことに、それはそれほど頻繁には発生しませんが、ハードドライブの使用可能なスペースの半分も（まだ）使用していないことは認めます。そうなると、瓦礫書き込みが頻繁に発生し、結果としてバックアップに時間がかかると思います。しかし、現在、それはプラッターの瓦礫の領域を回避するという非常に良い仕事をしていて、私は減速を示す多くの例を見つけるのに苦労しました。また、メタデータ（ジャーナル）のためにデバイスの未定義領域を利用しているようであり、これにより、あなたが説明した大規模な速度低下を回避しています。

また、読み取りが終了してコマンドプロンプトが戻った後、F2FSが残りのデータをフラッシュするのに約10秒かかることにも気づきました。データの損失を防ぐために、この時間中にデバイスをアンマウントしたり、取り外したりしないことが重要です。シェルスクリプトを使用している場合は、それを覚えておいてください。

F2FSを使用した私の書き込み速度は、xfsを使用して示した書き込み速度をはるかに上回っていることに同意していただけると思います。また、これを機能させるためにタイムアウトを変更する必要はありませんでした。

0
Mark Warburton