Jenom raději upozorním, že bcache od stejného autora trpěla od jádra 3.14 regresemi (deadlocky ve writeback režimu), které i přes bugreporty nikdo neřešil a netuším, jestli tam nejsou dodnes (naposledy jsem to zkoušela s jádrem 4.4.0 a regrese trvala, pak jsem nad tím zlomila hůl). Z mého pohledu si autor procpal bcache do upstreamu a pak se vykašlal na údržbu. Aby to s bcachefs nedopadlo podobně...
Zatial som to nepotreboval, ale vzdy som mal na pamati ze by som to mohol suplovat pomocou loop. Akuart to nieje take pekne .
napriklad ext4 subvolume:
truncate --size 500M /btrfs/sub/btrfsvol
mkfs.ext4 -F /btrfs/sub/btrfsvol
mount -o loop /btrfs/sub/btrfsvol /mnt/btrfsvol
pouzivat swap -> loop -> btrfs nie je dobry napad ... ano, ono to funguje, ale je dost vysoka pravdepodobnost, ze system skonci na "deadlock" podobnu situaciu ... tl;dr; btrfs zapisuje cez tranzakcie. V istych podmienkach nedostatku pamati moze nastat situacia, ze treba pouzit swap, ale nejde dokoncit tranzakciu pre nedostatok pamati.
Příznivec open-source rád píšící i o ne-IT tématech. Odpůrce softwarových patentů a omezování občanských svobod ve prospěch korporací.