ZFSはファイルシステムというよりデータベースのように記述されているため、ファイルの変更、移動、名前の変更をインテリジェントに管理するバージョン管理システムのように動作することを期待するのは妥当なようです。質問は特にスナップショットについて尋ねますが、スナップショットはクローンと多くの共通点があり、
スナップショットの後にファイルにそれ自体のハードリンクされたコピーがある場合、スナップショットは本質的に空のままになりますか?
BTRFSはZFSとほぼ同じことを行うように設計されているという提案がありますが、これらの条件で同じ動作をすることが期待されますか?
WindowsマシンがSAMBAを介してリモートでZFS共有にアクセスする場合、上記と同じ動作が当てはまりますか、それともSAMBAは標準のドライブ命令のサブセットになりますか?つまり、移動はコピーと削除になりますか?
上記の質問に一般的に答えることは可能ですか、それともすべて実装固有の答えですか?
コメント提供者の要求に応じて、以下は説明されている操作で実行されるテストです。
システムインフォメーション:
。
`zpool list` `zfs list`
POOL SIZE ALLOC FREE USED AVAIL REFER
プールを作成します:zpool create -m /test/mnt FILE-TEST /test/1.img /test/2.img
FILE-TEST 224M 80.5K 224M 73K 192M 19K
スナップショット:zfs snapshot FILE-TEST@1
FILE-TEST 224M 122K 224M 73K 192M 19K
FILE-TEST@1 0 - 19K
ファイルの作成:echo ‘test’ > /test/mnt/test.txt
FILE-TEST 224M 132K 224M 95K 192M 21K
FILE-TEST@1 17K - 19K
ファイルサイズを増やします: `head -c 128K /test/mnt/test.txt
FILE-TEST 224M 678K 223M 490K 192M 148K
FILE-TEST@1 17K - 19K
スナップショット:zfs snapshot FILE-TEST@2
FILE-TEST 224M 267K 224M 239K 192M 148K
FILE-TEST@1 17K - 19K
FILE-TEST@2 0 - 48K
ファイルを編集し、最後の4バイトを変更します。
FILE-TEST 224M 1.07M 223M 386K 192M 148K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
スナップショット:zfs snapshot FILE-TEST@3
FILE-TEST 224M 548K 223M 388K 192M 148K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 0 - 148K
ファイル名を変更する mv test.txt test2.txt
FILE-TEST 224M 552K 223M 404K 192M 150K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
スナップショット:zfs snapshot FILE-TEST@4
FILE-TEST 224M 1.06M 223M 645K 191M 150K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 0 - 150K
新しいフォルダ:mkdir /test/mnt/subdir
FILE-TEST 224M 716K 223M 420K 192M 151K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 9K - 150K
スナップショット:zfs snapshot FILE-TEST@5
FILE-TEST 224M 790K 223M 424K 192M 151K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 9K - 150K
FILE-TEST@5 0 - 151K
ファイルの移動:mv /test/mnt/test2.txt /test/mnt/subdir/
FILE-TEST 224M 584K 223M 444K 192M 151K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 9K - 150K
FILE-TEST@5 10K - 151K
スナップショット:zfs snapshot FILE-TEST@6
FILE-TEST 224M 602K 223M 447K 192M 151K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 9K - 150K
FILE-TEST@5 10K - 151K
FILE-TEST@6 0 - 151K
ハードリンクファイルを作成します:cp -l /test/mnt/subdir/test2.txt /test/mnt/subdir/test3.txt
FILE-TEST 224M 603K 223M 466K 192M 152K
FILE-TEST@1 17K - 19K
FILE-TEST@2 138K - 148K
FILE-TEST@3 10K - 148K
FILE-TEST@4 9K - 150K
FILE-TEST@5 10K - 151K
FILE-TEST@6 12K - 151K
上記からの観察:
- スナップショットの後にZFSでファイルが変更された場合、スナップショットは同じサイズで違いだけですか、それともファイル全体ですか?
異なるブロックはサイズを大きくします。
つまり、ファイルが100ブロックで構成されていて、1バイトを変更した場合(1バイトが1ブロックよりも小さいと仮定)、最後に1つの新しいブロック(合計101)が追加され、古いファイルはブロック1から100を参照します(スナップショットから読み取り専用でアクセスできます)、新しい/現在のファイルはブロック1から37および39から101(または実際の変更操作に応じて他の任意の組み合わせ)を参照します。
スナップショットを破棄するとすぐに、ブロック38は空きとしてマークされ、上書きできます(他のスナップショットがスナップショットを参照していない場合)。
- スナップショットの後にファイルがZFSで移動された場合、スナップショットは基本的にゼロサイズのままですか?
同じファイルシステム内では、メタデータは別として、はい(たとえば、参照を再配置する必要があります)。
ファイルシステム間では、ファイルシステムが同じプールまたは相互の子孫にある場合でも、完全なコピーと削除の操作になります。
- スナップショットの後にZFSでファイルの名前が変更された場合、スナップショットのサイズは基本的にゼロのままですか?
はい、メタデータは別として(たとえば、新しい名前をどこかに記録する必要があります)。
- スナップショットの後にファイルにそれ自体のハードリンクされたコピーがある場合、スナップショットは本質的に空のままになりますか?
ここで具体的に教えてください。
- BTRFSはZFSとほぼ同じことを行うように設計されているという提案がありますが、これらの条件で同じ動作をすることが期待されますか?
私はそれがすべて同じことをするとは思いません。
- WindowsマシンがSAMBAを介してリモートでZFS共有にアクセスする場合、上記と同じ動作が当てはまりますか、それともSAMBAは標準のドライブ命令のサブセットになりますか?つまり、移動はコピー+削除になりますか?
Windowsファイル共有には2つの実装が考えられます。SunforSolarisによって開発され、OpenSolaris/illumosでオープンソース化されたCIFSサーバー、またはほぼすべてのGNU/Linuxディストリビューションで使用されるSamba SMB実装です。およびBSDシステム:
2番目のケースでは、テストはしていませんが、他のシステムとほぼ同じであると思います。
- 上記の質問に一般的に答えることは可能ですか、それともすべて実装固有の答えですか?
Cコードを読みたい場合は、illumos/OpenZFSリポジトリ(Githubリポジトリ)にあるコードに従って具体的に回答するか、マニュアルページとドキュメントに従って一般的に回答することができます。たとえば、REFER、USEDなどのプロパティが詳細に説明されています。最も興味深いマンページはman zpool
(ハードウェア、ディスクレイアウト、プールプロパティ)、man zfs
(ファイルシステムのプロパティ、スナップショット、クローン)、man chmod
(Solaris/illumosのみ、ACLのファイルと共有)およびman zdb
(デバッグと分析)。