ここ最近ZFS絡みの記事をいくつか投稿してきました。
どの記事も、ZFS利用中に問題が起き、そして何となく解決した（解決しそう）という事を書いた記事で、問題が起きた原因や解決した理由を、勝手な想像レベルでしか記していませんでした。

実は今回も、バックアップを取った後、不必要になったデータセットをzfs destroyした後にマシンが停止し、再起動後プールのインポートが出来なくなりまして、こう立て続けに問題が起きると今後もずっと運用で困りそうなので、ZFSの事を少し勉強することにしました。
（ちなみに、もの凄く時間は掛かりましたが今回も何事も無かったかのように復帰させることができました。）
同じような問題を回避するため、そしてもし問題にぶち当たってしまったら落ち着いて正しい操作を行うためです。

で、色んなところに分散している情報を総合してここにまとめようかと思ってたのですが、ZFSの仕組みや起こりがちな障害とその対応の方法について（ユーザ目線から見ると）かなり詳しくまとめられてる素晴らしい記事を発見しました。

HRS’s Web Page – The Design and Implementation of the Gracious Days

ほんとに素晴らしい内容で、日常的にZFSを利用するユーザの方は読むべきだと思います。

リンク先の内容と、私の経験則を合わせてまとめておきます。
（私の経験則が混ざってるので鵜呑みにせずに是非リンク先を読んでください。具体的なコマンド例なども載っています。）
（長くなるので断定口調で書いてますが、環境、特にOSやzfsやzpoolのバージョンによって変わるはずです。すべて語尾に「〜かもしれない」が付いてるとお考えください。）

• ZFSは削除が遅い。
• 削除とはファイルの削除、スナップショットの削除・データセットの削除のことである。
• 削除処理はそのコマンドを発行した時点でトランザクションとして記録される。
• 削除処理は遅いだけでなく、通常運用中よりメモリを食う。
• FreeBSDの場合ZFSはカーネルで動作するのでメモリが不足するとマシンが止まる。
• （マシンが止まって再起動した後）zpool importすると、マウントされる前にまず未処理のトランザクションが処理される。（ロールバックではない）
• 未処理のトランザクション実行中にマシンが止まると再起動して何度もやり直すことになるが、マシンが止まらなかった場合（メモリが不足しなかった場合）と比べてトランザクションの完了までにトータルで数倍の時間がかかる。
• よってメモリはできるだけ大量に積んどいた方がいい。
• 削除処理の遅さ、メモリ消費量は、dedupオンでさらに数倍になる。

と、こんな感じでしょうか。
かなり致命的な欠陥のようにも思えますが、ちょっと考えればいくつか回避方法が思いつきます。
例えば削除処理を頻繁に行うデータセットではdedupをオンにしないとか、dedupオンのデータセットには数百GB以上レベルの単一の巨大なファイルを置かないとか、容量の大きなデータセットを削除するときは、中身を少しづつ消して空にしてから削除するとか、メインで使うプールと別にするとか。

コストが許容できるならメモリをたくさん載せるのが一番良いかなとは思いますが、今回の私の場合、数十GBのファイルをいくつかと細かいファイル多数で2TB近くあったdedupオンなデータセットの削除で、メモリ16GBあっても足りませんでした。
つまり何度も再起動させられました。
自分の用途だと通常利用中は4GBあれば十分で、いざという時のためだけにその4倍以上のメモリを積んどくのはもったいない気がします。
ちなみに今回、再起動に掛かった時間を省いてトランザクションの処理に掛かった時間だけを合計するとおそらく24時間は超えてます。

dedupは非常に先進的な感じがして、使いどころによっては非常に効果が高く、それなりのマシンなら通常利用でそんなに遅さも感じないので、結構気軽に使ってたんですが、今度から少し慎重になろうと思います。

とまぁZFSにはこんな欠点があるんですが、分かっていればなんとかなる気がしますし、他の長所の部分が大好きですので、これからもZFSをバリバリ使って行くと思います。