ZFS Copy-on-Write
ZFSファイルシステムが備えるCopy-on-Write（CoW）メカニズムは、あらゆる書き込み操作でデータを「上書きせず」に保存することで、ファイルシステム全体の完全性と信頼性を常に確保します。
新しいデータは別のブロックに安全に書き込まれ、すべての処理が正常に完了したことを確認してから切り替えられます。
この仕組みにより、途中で電源が落ちたり障害が発生しても、既存データは常に保護されたままです。
さらに、古いブロックは解放・再利用されるまでの間、フォレンジックレベルのデータ保持が行われ、万が一の障害解析やデータ検証にも対応できる堅牢な設計を実現しています。
1. コンセプト
NAS Proが採用するZFSは、データの完全性と信頼性を最優先に設計されたファイルシステムです。
Copy-on-Write（CoW）方式では、データの更新時に元のブロックは上書きせずに新しいブロックに書き込む仕組みを採用しています。
- データ更新時、元のブロックはそのまま保持されます。(Block#A)
- 新しいデータは新しいブロックに書き込まれます。(Block#A")
- 他のオペレーション参照が存在する限り、旧ブロックは保持されます。
- 書き込みが完了すると、新しいブロックが最新データとして参照されます。
2. スナップショット参照の構造
ZFSでは、過去のデータ状態を保持するスナップショット機能があります。
スナップショットは実際のデータをコピーするのではなく、参照情報（ポインタ）を保存することで構成されます。
- Block#A（スナップショット）
過去の状態を保持する参照ブロックです。
削除されず、安全に保持されます。 - Block#A"（Active Dataset）
現在のデータが格納されているブロックです。
スナップショットとは別の場所に書き込まれます。
3. 古いブロック解放のタイミング
| State | 状態 | 結果 |
|---|---|---|
| Snapshot対象 | 旧ブロック参照中 | 削除されない・削除保留 |
| Snapshot削除 | その他参照無し | フリーリストに追加 |
| 次のトランザクション処理 | 再利用にマーク | 新しい書き込みによる上書き |
この仕組みにより、障害や書き込み途中のトラブルが発生しても、既存データは安全に保持されます。
また、不要になったブロックは効率的に再利用され、ストレージ容量の最適化も実現されます。
4. Forensic版の適用
フォレンジックエディションは、ZFSの参照構造をそのまま活かしながら、データの不変性と長期的な証拠保全を保証する設計です。
監査・証拠管理用途など、変更履歴の完全保持が求められる環境に最適化されています。
-
主な機能：
- 自動ロック化および削除不可のスナップショット処理
- 永続的な参照カウンター（「フォレンジックロック」）による改ざん防止
- 重要スナップショットのGU削除機能無効化
- 定期的なzdb検証および参照ログエクスポート
これにより、ストレージ上のデータは論理的にも物理的にも保護され、長期間にわたって真正性を維持したまま証拠保存が可能となります。
ZFSファイルシステム 定期・差分レプリケーション実行
Windows Serverからアクセスされる「forensic node」を介して、ZFSファイルシステム上ではEvidence（原本）とCase（解析データ）を分離して管理します。
データの更新はCopy-on-Write方式により新しいブロックに書き込まれ、その都度デジタル署名付きスナップショットとして保存されます。
バックアップノードには、原本データとフォレンジック処理後の複製が保持され、ZFSの自動検証機能によって長期間にわたる完全性と信頼性が保証されます。
ZFSファイルシステム architecture
以下の図は、ZFSファイルシステムを中核にしたストレージサーバの全体アーキテクチャを示しています。
最下層の Debian Kernel の上に Open ZFS が実装され、その上位に Samba（SMB/CIFS） によるファイル共有サービスが構築されています。
各モジュール（認証、ネームサービス、ウイルスフィルタ、DFS など）は Samba と連携し、API・SSH・WebUI を通じて統合的に管理できます。
このように、ZFSを中心とした階層構造により、データ整合性・拡張性・管理性を高いレベルで両立しています。
続く図では、この中核を担う Open ZFS の仕組みと特徴について詳しく説明します。
Open ZFSの仕組みと特徴
上図では、システム全体の構成と各サービスの関係を示しました。
ここでは、その中核を担う Open ZFS の内部動作、特に同期書き込み処理における ZIL（ZFS Intent Log） と SLOG（Separate Intent Log） の関係を示しています。
ZFS では、すべての書き込み要求がまず RAM 上のメモリキャッシュに保持され、同期書き込み（O_SYNC や NFS の commit 操作など）の場合は ZIL にトランザクションとして記録されます。
通常は ZIL がプールデバイス上に配置されますが、SLOG デバイスを追加することで、ZIL の書き込み処理を NVMe SSD など高速な I/O を提供する専用デバイスにオフロードし、低レイテンシなトランザクション処理と高スループットを実現します。
SLOG はキャッシュデバイスではなく、同期書き込みの永続性を保証するためのジャーナル領域として機能します。
トランザクションがメインプールにコミットされると、SLOG のデータは解放されます。
これにより、システムは RAM 経由の高速パスと SLOG 経由の信頼性確保を両立し、エンタープライズ用途でも高い可用性を維持します。
