ChienomiChienomibtrfsのsnapshot/send/receiveの挙動を検証するスナップショットと容量とリネーム(mv)send/receiveサブボリューム名とシンボリックリンクスナップショットと容量とリネーム(mv)最初の状態。追加した分以外がsharedで、サイズが増えているのはsnapshotではなくワーキングボリューム。.新規にスナップショットを取ると増えたファイルもsharedに入った。.もう一度ファイルを増やす。.そしてスナップショット。.mvしてみると、ファイル名は異なっているが、sharedの量は増えていない。mvは理解してくれるらしい。ファイル名ではなく実体の問題。fileEとしてみた。別ファイルとして扱われ、sharedの量が減っている。3つ目のスナップショットを取る前の状態に。falsemvして、ファイルを追加した。.shareされていないのは追加されたfileFだけ。ここでスナップショットを取っておく。.send/receiveさて、ここからsend/receiveを試してみる。send1使用量通りと考えていいだろう。次にsnap3に基づいて作ってみる。容量は差分容量通りといった感じ。send2それぞれの差分を作る。sendsnap2-3全サブボリュームを削除してみる。'/mnt/1/test1'最新ボリュームのsend2をreceiveしてみる。subvolume元になるサブボリュームがないとだめらしい。sendsnap-latest順当に行える。sendsnap-latestを削除して、ベースになるsend3をリネームしてみる。snap2sendsnap-latestはsnap3というサブボリュームに基づいて作られていたが、snap3という名前のサブボリュームは、sendsnap-baseという名前に変更されてしまったため、もうない。一致する名前はなくても正しく書き戻すことができた。fileFということは名前ではなく、IDなどで判断しているのだろう。元になったサブボリュームが存在していればOKだ。.全くシェアはされていないが、シェアフラグを削除し、データは消していないようだ。ハードリンクのような仕組みだろうか。send2を戻してリンクしてみる。fileFこうなった。マウントするサブボリュームの切り替えは、set-defualtでも良いが、シンボリックリンクを論理的な名前にすることも可能なようだ。