…jeden sendne a druhý to bude přijímat ?

Rozhodně NE. send a receive je potřeba pouze pro kopírování mezi různými FS; v rámci jednoho FS je to naprosto zbytečný overkill.

Přesun a přejmenování subvolume — dle libosti!

Subvolume lze v rámci jednoho filesystému přesouvat a přejmenovávat skoro jako běžné adresáře. Pojďme si to předvést!

btrfs subvolume create sub1{,/a} sub2{,/b}
ls -R sub{1,2}

Jenom tak, čistě bezdůvodně, prohodíme „vnořené“ subvolume — ve skutečnostni nejsou nikam vnořené, viz níže —, nejjednoduším možným způsobem:

mv sub2/b sub1/
mv sub1/a sub2/
ls -R sub{1,2}

A teď to prohodíme zase zpátky, ale schválně jiným způsobem, jenom tak pro zajímavost a pro ilustraci a pro potěšení a pro zábavu a pro dobrý pocit typu „tak teď fakt používám Btrfs“:

btrfs subvolume snapshot sub1/b sub2/b
btrfs subvolume snapshot sub2/a sub1/a
ls -R sub{1,2}
btrfs subvolume delete sub1/b sub2/a
ls -R sub{1,2}

A teď ten zbývající bordel zase po sobě uklidíme:

btrfs subvolume delete sub1{/a,} sub2{/b,}

Subvolume u Btrfs ve skutečnosti nejsou „zahnízděné“!

Klíčové pozorování z předchozí kapitoly: Zahnízdění do sub1 a sub2 je v tomto případě v podstatě zbytečné. Stejně jako jakékoliv pokusy o hierarchii subvolume.

Na rozdíl od ZFS, který má paralelní strom subvolume, který přímo nesouvisí s adresářovým stromem souborového systému ani s mout pointy a je hierarchicý, Btrfs nic takového nemá.

Subvolume a snapshoty v Btrfs (což je z hlediska použití skoro totéž) jsou ploché, bez hierarchie, identifikované pouze pomocí subvolid. Manuálová stránka o tom malinko mlží, ale v podstatě to tam je.

A subvolume in BTRFS can be accessed in two ways:
• like any other directory that is accessible to the user
• like a separately mounted filesystem (options subvol or subvolid)
In the latter case the parent directory is not visible and accessible. This is similar to a bind mount, and in fact the subvolume mount does exactly that.

Tady ještě jednoduchý přehled, jak je to s tou atomicitou:

Kdo nevěří, ať tam běží!

Cituji z manuálové stránky:

What should be mentioned early is that a snapshotting is not recursive, so a subvolume or a snapshot is effectively a barrier and no files in the nested appear in the snapshot. Instead there's a stub subvolume (also sometimes empty subvolume with the same name as original subvolume, with inode number 2). This can be used intentionally but could be confusing in case of nested layouts.

Tady je jednoduchý příklad (ne)atomicity (ne)hierarchických subvolume:

btrfs subvolume create sub1{,/a}
touch sub1/a/blah
btrfs subvolume snapshot sub1 sub2

Tedy ještě jednou: Subvolume (ani snapshoty) u Btrfs nejsou hierarchické; nefunguje to jako oddělená hierarchie subvolume u ZFS:

ls -Rl sub{1,2}    # <<< sub2/a NENÍ subvolume a NEOBSAHUJE blah
stat -c%i sub2/a   # <<< 2, přesně jak říká manuálová stránka!
touch sub2/a/blah  # <<< zamítnuto! tohle není běžný adresář!

Důvod, proč sub2/a není (ani) skutečný adresář (jakým by byl třeba běžný mount point) je předcházení omylům a nesrovnalostem, kdy někdo v daném adresáři buď něco očekává, nebo do něj něco zapisuje atd. Pojďme to zase uklidit! A povšimněme si, že sub2/a není třeba nijak uklízet, protože to není usbvolume:

btrfs subvolume delete sub1{/a,} sub2

Počkat! Ale co kdybychom chtěli mít také snapshot sub1/a v sub2/a? Inu, museli bychom ho odzrcadlit manuálně a neatomicky. Například:

btrfs subvolume create sub1{,/a}
touch sub1/a/blah
btrfs subvolume snapshot sub1 sub2      # <<< Začátek race window!!1
rmdir sub2/a                            # <<< Jo! Tohle jako fakt!
btrfs subvolume snapshot sub1/a sub2/a  # <<< Konec race window!!!

ls -Rl sub{1,2}       # <<< sub2/a JE subvolume a OBSAHUJE blah
stat -c%i sub{1,2}/a  # <<< subvolid kořene (!= 2) (nedokumentováno)

btrfs subvolume delete sub{1,2}{/a,}    # <<< Teď jsou obě sub{1,2}/a subvolume.

V případě Btrfs se tedy atomicita snapshotů nepropaguje „přes mount point“.

Je to důležité?

V mnoha případech to není příliš podstatné; potřeba atomicity přes několik subvolume může svědčit o špatném návrhu adresářové struktury — například použití subvolume tam, kde by měly být obyčejné adresáře.

Leč pravda je, že ZFS má v tomhle jednom ohledu jakousi drobnou „výhodu“ — nebo přinejmenším feature navíc.