web-dev-qa-db-ja.com

シフトが間違っているZFS zpool。これはどれくらい悪いですか？

3x1TB ZFS（ZoL）RAIDZ1があります。 1つのドライブが故障しました。私はそれを4TBのディスクに置き換えています。

$ Sudo zpool replace pool <old guid> /dev/disk/by-id/<new id>

cannot replace <old guid> with /dev/disk/by-id/<new id>: 
new device has a different optimal sector size; 
use the option '-o ashift=N' to override the optimal size

$ zdb -C | grep ashift
            ashift: 9

$ Sudo zpool replace pool <old guid> /dev/disk/by-id/<new id> -o ashift=9

これは動作します。これで、アレイは再同期化されました。しかし、正直なところ、この設定の影響を理解していませんでした。障害のあるディスクをできるだけ早く交換し、近い将来に他の1TBディスクを4TBディスクに交換したかっただけです。しかし、後知恵では、2 ^ 9のAlignment Shiftを使用したパフォーマンス 恐ろしいと説明されています 。

この設定は不変であることを理解しています。他の2つのディスクを交換した後、ashift値を2 ^ 12に変更することはできません。これは、正しく理解すれば4TBディスクに推奨されます。

私は足で自分を撃ちましたか？どのように進めるのが最善ですか？ autoexpandを無効にして、ashift=12で新しいアレイに新しいボリュームを作成し、古いドライブを同じドライブの新しいボリュームにコピーできますか？それは可能ですか？

hard-driveraidzfs
1
Redsandro

小さすぎるashift値を選択すると、書き込みを行うときにディスクが内部的に読み取り-変更-書き込みを行うことになります。パフォーマンスの低下に気付くかどうかは、使用パターンによって異なります。多くの同期書き込みを行い、非常に高いパフォーマンスが必要ですか？答えが「はい」の場合、違いに気付くでしょうが、違いがある場合は気付かないかもしれません。 ZFSはこれらの書き込みをまとめて大きなマルチブロック更新にバッチ処理するため、非同期書き込みはこの影響を受けません。つまり、大量のサブブロック書き込みはありません（大きな連続書き込みの最初と最後のブロックのみがサブ-ブロック）。

4KiBブロックに切り替える主な欠点は、圧縮されたブロックを最も近い512Bではなく、最も近い4KiBにしか丸めることができないため、圧縮が機能しないことです。トップエンドの書き込みパフォーマンスよりも重要な場合は、そのままにしておいてください。

書き込みパフォーマンスが本当に重要な場合は、プールを再構築する必要があります。最も簡単な方法は、zfs send/zfs receiveを、希望する方法で構成された新しいプールに対して行うことだと思います。

新しいプール用のすべてのハードウェアを一度に購入してクリーンsend/receive：を実行するのを避けるための具体的な提案については、すでにashift 9でデータが書き込まれているため、 'ashift 12のディスクをプールに追加しません（ZFSは、4KiBに位置合わせされたディスク上で512Bに位置合わせされたブロックをアドレス指定できません。ashiftは最上位vdevsの設定です（ディスクではなく）—したがって、警告が表示されます。新しいドライブの後半に新しいプールを作成し、最初のプールからすべてのデータをコピーすることは可能かもしれませんが、その冗長性は元のプールと同じではありません。 1つのディスクの1つのパーティションからRAIDZ1を構築します。冗長性なしで2番目のプールにコピーし、元のプールのディスク/パーティションを正しいashift /冗長性に再構成してから、すべてのデータをコピーして戻すことができます。

1
Dan