3つのTBディスクで満たされた8つのディスクベイを備えたサーバーがあります。それぞれ2つのディスクの4つのミラー化されたvdevを使用すると、12 TBの冗長ストレージが得られます。
ここに問題があります-「x GBのRAM for each TB of deduped data)」(言い換え)が必要だとどこかで読みました。私のプールに重複排除できないデータがほとんど含まれている場合、RAMをあまり使用しません。残念なことに、「重複データ」とは、重複したプール内のすべてのデータが有効になっていることを意味しているようです。
その結果、おそらくRAMが足りなくなったためにシステムがロックアップし始め、リセットする必要がありました。間違いに気付いたとき、重複除去を無効にした新しいデータセットを作成し、すべてのデータを新しいデータセットにコピーしてから、古いデータセットを破棄することで修正できると考えました。幸い、プールの約35%しか満たしていません。これを試す前に、すべてのデータセットで重複除去を無効にしました。
残念ながら、古いデータセットから何かを削除しようとすると、システムの16スレッドすべてが100%になり、24 GBのRAMがすべて突然いっぱいになります(htop
で確認できます)。その後、システムがロックします。 。
プール全体を破壊してやり直すことなく、この穴から掘り出す方法はありますか?
私は実際に自分でこれを見つけました。システムが起動時にZFSボリュームを自動的にマウントしていました。システムを正常に起動した場合、起動中に「Mount ZFSデータセットの開始ジョブが実行されています...」というテキストまたはその効果でフリーズします。レスキューモードで起動した場合、正常に起動してプロンプトが表示されますが、ZFSはバックグラウンドでデータセットを静かにマウントしようとし、最終的に10〜15分後にマシンをロックします。さらに、これによりプールに変更を加えることができなくなりました。
Systemdタスクzfs-mount.service
を無効にし、再起動してレスキューモードでこれを回避しました。これで、マシンをロックすることなく、選択的にデータセットをマウントしてプールに変更を加えることができました。
私はまだ私の問題を解決していません。重複除去を無効にして、重複排除されたデータセットからすべてのデータを新しいデータセットにコピーし、古いデータセットを削除したにもかかわらず、依然として巨大なDDTがあります。
dedup:DDTエントリ29022001、ディスク上でサイズ975、コア内で315ブロックLSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- --- ------ 1 27.7M 2.78T 2.78T 2.78T 27.7M 2.78T 2.78T 2.78T 2 1.65K 191M 191M 191M 3.30K 382M 382M 383M 4 71 4.27M 4.27M 4.39M 310 19.4M 19.4M 19.8M 8 132 16.3M 16.3M 16.3M 1.18K 149M 149M 149M 16 3 32.5K 32.5K 36K 51 537K 537K 600K 4K 1 16K 16K 16K 6.61K 106M 106M 106M 128K 1 128K 128K 128K 146K 18.3G 18.3G 18.3G 合計27.7M 2.78T 2.78T 2.78T 27.8 M 2.80T 2.80T 2.80T
ただし、「RAM不足」の部分を見つけたので、この問題は解決したと考え、必要に応じて後で新しい質問を投稿します。
クイック編集: DDTは縮小しているようで、その速度は非常に速いです。おそらくそれはしわくちゃになり、やがて消えます。我々は見るであろう。
別のクイック編集:すばらしい!最終的にコマンドzpool status -D tank
がdedup: no DDT entries
を返すまで、DDTはどんどん速く収縮しました。