Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: asdffff 30. 06. 2020, 10:05:26
-
Ahojte,
už nejaký čas používam kombináciu OverlayFS, tmpfs a squashfs ako dočasný, prekrývajúci súborový systém:
- overlayfs, kde lowerdir je zložka z môjho lokálneho disku a upperdir je tmpfs mount
- squashfs používam na snapshoty zmien z upperdir. Ak chcem nejaký snapshot neskôr použiť, mountnem tento squashfs image a remountnem pôvodný overlayfs mount tak, aby bol medzi lowerdir cestami zahrnutý aj mount toho squashfs imidžu
- v prípade potreby sa dajú vykonané zmeny zapísať späť na disk
spravil som si malý program, ktorý to celé automatizuje.
Využívam to v prípadoch, kedy ma nebude trápiť, že by som o tie uložené dáta prišiel:
- výstupy z kompilácie
- keď len niečo skúšam a nechcem si zasviniť disk
RAM pamäť je vzácny zdroj. Blbé je, že zmeny ktoré OverlayFS ukladá, nie sú zrovna kompaktné. Pred tým ako otvorím nejaký súbor na zápis, musí sa celý skopírovať do upperdir. Všetky zápisy sa vykonajú na tejto kópii. Ak je pôvodný súbor veľký, ale zmien málo...
Plánujem preto vytvoriť FUSE filesystem, ktorý by mal správanie porovnateľné s overlayfs+tmpfs+squashfs, ale hospodáril s pamäťou lepšie. Priznám sa, že som takéto niečo ešte nerobil, každopádne je to zaujímavý problém.
Aktuálne zberám use-casei, kde by sa niečo takéto dalo reálne využiť - mimo mojej domácej spotreby. Myslíte, že sa oplatí do tohto investovať čas, alebo je to zbytočnosť? Vidíte nejaké iné prípady použitia? Virtuálky/kontajnery + read-only sieťový disk?
Vďaka za akékoľvek nápady!
-
Než dáte rok života do FUSE, koukněte se na device mapper, jeho "snapshot" target.
V podstatě vezmete lower device (může, ale nemusí být read-only), vezmete nebo vytvoříte upper device (/dev/ram0, /dev/loop0, ... fantasii se meze nekladou), a spojíte je do jednoho:
lower=/dev/sda1
upper=/dev/ram0
size=$(blockdev --getsz "$lower")
chunks=8 # granularita v 512B blocích
echo "0 $size snapshot $lower $upper P $chunks" | dmsetup create kybl
Potom si už můžete /dev/mapper/kybl připojit a používat. Zapsané změny oproti $lower se zapíší ve 4K blocích do $upper.
Když chcete, můžete změny z $upper propsat do $lower (nebo do třetího block device), konkrétní dm-inkantaci si dohledejte :)
-
Taky zvazuji napsat vlastni "meta/cache/tieredFS" (ale treba to uz existuje), protoze bcache mi nevyhovuje (nelze pridat na existujici device, kdyz detekuje stream velkeho souboru tak se necachuje, a je to spis neriditelnej blackbox).
Moje predstava je:
- Jeden NVMe proxy/cache filesystem device (dale SSD)
- Vicero klasickych diskovych poli (dale HDD), muzou byt jak lokalni tak remote
Do SSD se nakopiruje:
- cela adresarova struktura HDD (vsech poli, jako union) - inody + lookup tabulky
- soubory urciteho adresare (aktualni projekt na kterem se dela)
- male soubory (do volne kapacity)
System (at uz lokalni, nebo pres nfs/smb) pracuje tedy primarne s tim SSD - ucel je urychlit prohledavani disku a operaci s malyma souborama. A taky to, aby se pole HDD zbytecne neodparkovalo kazdou chvili, pripadne aby ho slo i zcela zastavit. Podpora vicero lower cest je nutna - chci mit globalni SSD cache, pro vsechna HDD pole (je lepsi mit vicero nezavislych svazku, rekneme po 6-8 discich, nez treba trvat na tom, ze system bude funkcni jen kdyz bude online vsech "sto" disku).
Vsechny zapisy pujdou jdou jenom do SSD (i kdyby se jednalo o nn GB novych videozaznamu, radove uvazuji o 4T SSD s 1T free space, 3T cached, z 50T hdd poli), a mimo pracovni dobu / v noci se provede flush na HDD pole, a eject z flashe nepotrebnych veci (at uz starych, nebo velikych).. on ten eject muze byt udelan i kdyz dojde volne misto.
Chci, aby ta cache vrstva pouzivala klasicky filesystem (ext4) a treba skrze extended attributy delala ty "cross-device hardlinks", s tim ze overlay se zmenama, nebo nacachovane casti souboru budou reprezentovany jako sparse file (samozrejme musi ke kazdemu bloku byt pak jeste modified flag). Zmeny v adresarove strukture se daj reprezentovat v ramci SSD drzenim dvou vetvi - jedna co dela jen cache 1:1 k hdd strane (per hdd), a druhou, ktera je viditelna k uzivateli. Pripadne snapshoty se daj resit pak skrze vicero techto uzivatelskych casti.
Ohledne zaloh.. pri zapisu do nizsi vrstvy lze generovat log zmen, ktery by sel prenest a drzet v zaloznim stroji, dokud tam bude misto, ty inkrementy se nemusi aplikovat a dovoli rollback kdyby se smazalo neco co nemelo.
Najde se treba nejaky student co by tohle chtel resit? :-)
-
Než dáte rok života do FUSE, koukněte se na device mapper, jeho "snapshot" target.
V podstatě vezmete lower device (může, ale nemusí být read-only), vezmete nebo vytvoříte upper device (/dev/ram0, /dev/loop0, ... fantasii se meze nekladou), a spojíte je do jednoho:
lower=/dev/sda1
upper=/dev/ram0
size=$(blockdev --getsz "$lower")
chunks=8 # granularita v 512B blocích
echo "0 $size snapshot $lower $upper P $chunks" | dmsetup create kybl
Potom si už můžete /dev/mapper/kybl připojit a používat. Zapsané změny oproti $lower se zapíší ve 4K blocích do $upper.
Když chcete, můžete změny z $upper propsat do $lower (nebo do třetího block device), konkrétní dm-inkantaci si dohledejte :)
Áno, to by bolo asi super riešenie, ak by som potreboval overlaynut celé blokové zariadenie. Tu ma ale zaujíma len nejaký podstrom moutnutého fs, nad ktorým môžem robiť (dočasné) zmeny.