編集:(この質問の最後を参照)さらに掘り下げた後、これはシステムのUSBの問題であり、ドライブがキックされる原因となっているZFSではないようです。答えがあるかどうかまだ気になるので、この質問は後世に残しておきますが、とりあえずFreeBSD USBデバイスからの強制的な削除に関するアドバイスがあれば、私はすべて耳にしたことになります
ユーモアのセンスを持ってこの質問に近づいてください、そしてそれは悪い考えです、時々(非常にまれです!)ユーザーが完全にであるので、単に投票しないでくださいデータ損失はありますが、フットガンのロードの助けが必要です!結局のところ、ZFSにはデータの整合性以外にも他のメリットがあります。私はext4
よりも、不良ドライブにそれを使用したいのです。あなたがずるい笑顔でこれを読んで、正確にこれを行うことによってデータを失った時間を覚えているsysdminのタイプであるなら、この質問はあなたのためです。
重要ではないデータを備えた重要ではないサーバー上で、いくつかのUSBドライブを備えたプールを実行していますが、破損してもかまいません。チェックサムエラーが発生したときにZFSがUSBドライブを強制的に削除しないように設定しようとしています(ext4またはFATがデータ損失に気付かない/気にしないことでこのシナリオを処理するのと同じように)。
読者がZFSプールを修正しようとしてGoogle経由でここに着陸した場合、この質問またはその回答で説明されていることは何も試みないでください。データが失われます!
ZFSの警察は、USBドライブを使用している、またはその他の非標準的な設定をしている人々に怒鳴りつけるのが大好きなので、この議論のために、私が128の冗長SSD上の32の物理的に離れた場所にバックアップした猫のビデオであると想定します。これを行おうとすると、このプールでデータが100%失われ回復不能に(何度も繰り返し)なることを完全に認めます。この質問は、ZFSを実行できる環境がどれほど悪いかに興味がある人(システムを限界点まで押し上げるのが好きな人、ちょうど楽しみのために)。
hdd
と2つのドライブ(failmode=continue
を設定)信頼性の低いドライブの原因は、サーバーのUSBバスのソフトウェアまたはハードウェアの問題であり、ケーブルの信頼性やドライブの物理的な問題ではないことを確認しました。私がこれを確認した方法は、正常なUSBポートを搭載したMacBookに接続し、ゼロ化してからドライブ全体にランダムデータを書き込んで検証することです(3回実行、毎回100%成功)。ドライブはほとんど新品で、他のSMARTインジケーターが100%のヘルスを下回っていません。ただし、ドライブが徐々に故障し、あちこちで数ビットが失われていても、問題ありません。
不良ドライブにチェックサムエラーがあると、ZFSはそれをプールから削除します(編集:これは誤った仮定であることが判明し、システムはZFSではなくキックしました)。残念ながら、FreeNASでは、物理的に再起動するか、USBケーブルとの両方を取り外して再接続しない限り、プールに再度追加することはできません供給。つまり、サーバー全体を再起動せずに再追加プロセスをスクリプト化したり、リモートで実行したりすることはできません。物を抜くために物理的に立ち会うか、インターネットに接続されたArduinoとリレーを両方のケーブルに配線する必要があります。
この種のことが可能かどうかについてはすでにかなりの調査を行っていますが、関連するスレッドが見つかるたびに、データ整合性ポリスが飛び込み、質問者を無視する代わりに信頼できない設定を放棄するように説得します。エラーまたはそれらの回避策。これを達成する方法についてのドキュメントやその他の回答が見つからなかったので、ここで質問します。
zfs set checksum=off hdd
を使用してチェックサムを完全にオフにします。チェックサムを保持したいので、ドライブが正しく動作していないことを確認したいので、まだ完了していません。エラーは無視します。zpool clear hdd
を実行して、しきい値に達する前にチェックサムエラーをクリアするhw.usb.xhci.use_polling=1
を設定する実験も行っていますが、まだ最終的な結果は得られていませんスナップショット、データセット、送信/受信などの他のすべてのZFS機能が必要なため、ext4
またはUSBエラー後にドライブを強制的に削除しない別のファイルシステムを使用する必要がないようにしています。 、ドライブを切断せずにデータ整合性エラーを無視または修復しようとしています。
これは、ドライブが誤動作して削除された場合のdmesg
出力です
Jul 7 04:10:35 freenas-lemon ZFS: vdev state changed, pool_guid=13427464797767151426 vdev_guid=11823196300981694957
Jul 7 04:10:35 freenas-lemon ugen0.8: <Western Digital Elements 25A3> at usbus0 (disconnected)
Jul 7 04:10:35 freenas-lemon umass4: at uhub2, port 20, addr 7 (disconnected)
Jul 7 04:10:35 freenas-lemon da4 at umass-sim4 bus 4 scbus7 target 0 lun 0
Jul 7 04:10:35 freenas-lemon da4: <WD Elements 25A3 1021> s/n 5641474A4D56574C detached
Jul 7 04:10:35 freenas-lemon (da4:umass-sim4:4:0:0): Periph destroyed
Jul 7 04:10:35 freenas-lemon umass4: detached
Jul 7 04:10:46 freenas-lemon usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored)
Jul 7 04:10:52 freenas-lemon usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_TIMEOUT
Jul 7 04:10:52 freenas-lemon usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored)
Jul 7 04:10:58 freenas-lemon usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_TIMEOUT
Jul 7 04:10:58 freenas-lemon usb_alloc_device: Failure selecting configuration index 0:USB_ERR_TIMEOUT, port 20, addr 9 (ignored)
Jul 7 04:10:58 freenas-lemon ugen0.8: <Western Digital Elements 25A3> at usbus0
Jul 7 04:10:58 freenas-lemon ugen0.8: <Western Digital Elements 25A3> at usbus0 (disconnected)
これは、不良ドライブがキックされた後のzpool status hdd
出力です。
pool: hdd
state: DEGRADED
status: One or more devices has been removed by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub repaired 0 in 0 days 00:53:45 with 0 errors on Sun Jul 7 17:19:41 2019
config:
NAME STATE READ WRITE CKSUM
hdd DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
gptid/6a8016b8-a08d-11e9-8e1c-ecb1d765a86d ONLINE 0 0 0
11823196300981694957 REMOVED 0 0 0 was /dev/gptid/6c3950c1-a08d-11e9-8e1c-ecb1d765a86d
errors: No known data errors
編集:
さらに掘り下げた後、他の人々もこの種のエラーを経験したようです。カーネルのバグか、一部のドライブのUSBハードウェア/ソフトウェアの問題のいずれかであり、ZFSレベルの問題ではないようです。システムがドライブをキックしているため、ZFSチェックサムエラーが発生し、その逆は発生しません。 ZFSは再起動後に問題なくドライブを再インポートし、エラーを修正してデータの損失を報告しません。 USBの問題は、電源管理機能またはドライブでサポートされていない他のUSBコマンドに関連している可能性がありますが、2つのドライブは1年だけ購入した実質的に同一のWD Elementsドライブであるため、私はまだ懐疑的です。 camcontrol rescan all
は、接続が解除された後、接続されているUSBデバイスも検出せず、実際に完全に再起動し、多くの場合、外部ドライブの完全な電源再投入さらに再起動します。
失敗時のdmesg
出力:
ugen0.8: <Western Digital Elements 25A3> at usbus0 (disconnected)
umass4: at uhub0, port 20, addr 7 (disconnected)
(da4:umass-sim4:4:0:0): READ(10). CDB: 28 00 42 78 cd 98 00 01 00 00
(da4:umass-sim4:4:0:0): CAM status: CCB request completed with an error
(da4:umass-sim4:4:0:0): Retrying command
(da4:umass-sim4:4:0:0): READ(10). CDB: 28 00 42 78 cd 98 00 01 00 00
(da4:umass-sim4:4:0:0): CAM status: CCB request completed with an error
(da4:umass-sim4:4:0:0): Retrying command
...(same thing repeated)...
(da4:umass-sim4:4:0:0): READ(10). CDB: 28 00 42 78 f1 98 00 01 00 00
(da4:umass-sim4:4:0:0): CAM status: CCB request completed with an error
(da4:umass-sim4:4:0:0): Error 5, Retries exhausted
da4 at umass-sim4 bus 4 scbus7 target 0 lun 0
da4: <WD Elements 25A3 1021> s/n 5641474A4D56574C detached
(da4:umass-sim4:4:0:0): Periph destroyed
umass4: detached
私は喜んでUSBエンクロージャを使用して自分の足を撃っています。FreeNAS(まあ、FreeBSD)は、SCSIプロトコルを正しく実装していない(ほとんどの場合、何もしない)と言って、このエンクロージャに腹を立てているので、Linuxに切り替えました( ZoL)。ドライブが定期的に切断されていないにもかかわらず(dmesgが示す限り)、最初のドライブは読み取りとそこからのチェクサムエラーを報告し、そのようなバッチで1つ(同じインターフェイスに接続されている4つのうち)をキックしました。
結局、zfs_checksum_events_per_secondを20から0に調整することで、スクラブがスポークせずに完了するようにしました。
BSD側でドライブを開始するものを特定できませんでしたが、OPは、あきらめているのは実際のUSBインターフェイスであると述べました。