Názory k článku
Linus Torvalds má výhrady ke kódu Bcachefs pro 6.9
-
Bacha, to co myslel Linus nebylo MAD ale AAD (https://en.wikipedia.org/wiki/Average_absolute_deviation) - MAD obsahuje výpočet mediánu, což se nedá dělat iterativně...
-
Protože umožňuje mít data na rotačních discích a často používané bloky cachovat na SSD. Mělo by to být výkonnější než LVMcache, ale zkušenost nemám.
Vlastnosti filesystemu jsou zde:
https://bcachefs.org/Osobně mám negativní zkušenost někdy z roku 2014 s předchozím projektem stejného původního autora, tehdy byla v bcache dost vážná regrese způsobující zamrznutí systému a ztrátu dat a i přes reporty a přes to, že bcache byla součást upstreamu, ji dlouho nikdo neopravoval. Takže bych si nástupce asi netroufla nasadit do ostrého provozu. Ale může to už být jen moje paranoia, jsme o deset let dál...
-
Ale BCACHE byla obycejna pruchozi cache, k blokovemu zarizeni, neco co ted je treba skrze device mapper dostupno (dm-cache). Tenkrat to melo dost problem s tim, aby se spravne sestavili a spojili cachovane a cachujici zarizeni, pac to jaksi nemelo univerzalni kontejner.
u BCACHEFS pisou na strankach featury ktere maji bezne filesystemy - a vicemene vidim kopii BTRFS (cow,snapshoty,raidy,atd.).
-
Jasně, mně spíš jde o to, že se tehdy správce na ten problém naprosto vybod. Lidi tehdy zkoušeli dělat patche metodou pokus-omyl, ale když po půl roce stále pořádně nefungovaly, přestala jsem to testovat i sledovat. Takže bych byla opatrná s nasazením jeho dalšího projektu.
Jinak ano, toto je filesystem, který ovšem navazuje na původní bcache a sdílí s ním podstatnou část kódu, viz výše uvedený odkaz na Wikipedii.
15. 3. 2024, 13:05 editováno autorem komentáře
-
Co se tenkrát stalo už je jen pro pamětníky (a archivy):
"The archives remember where it started, https://lore.kernel.org/all/20150831205708.GB17467@kmo-pixel/ . In 2016 bcache got marked as Orphaned ( https://git.kernel.org/linus/4d1034eb7c2f5e32), then two other people picked up the work (https://git.kernel.org/linus/77c77a98f8a4dd4d33 until https://git.kernel.org/linus/d88b6d04447bbfd0b55) and then https://git.kernel.org/linus/e9938f552fc279e87af until today."
-
Bcachefs ma v nazve bcache, lebo je odvodeny od bcache cache subsystemu.
Pre porovnanie kam bcache pasuje napr pri porovnani so ZFS, najprv opisem ZFS. Z toho vieme potom odvodit linux analogy.
ZFS ma pyramidalnu strukturu, ktorej root tvori takzvana ARC (adaptive replacement cache), ktora existuje IBA v memory, a kde sa deje vsetka modifikacia IO related so ZFS. Tak by sa dalo povedat, ze ZFS je vlastne in-memory filesystem :).
ARC svojou cinnostou tvori akesi casove/transakcne prudy, nie nepodobne git commitom. Vsetka klasicka systemova IO aktivita sa deje len voci ARC. Charakter a design ARC sposobuje, ze klasicke random access IO writes do ARC sa serializuju na ZFS transakcie a z ARC potom uz len vystupuje akysi neustaly datovy stream snapshotov, ktore sa zapisuju na samotne storage devices. V tomto sa ZFS viac podoba na databazu, alebo napr Kafku. Pod ARC je to teda akoby streamovy system.
Treba si uvedomit, ze len samotna ARC ma aktualny obraz storage operacii, setky nizsie vrstvy uz vidia len obrazy ARC reality z minulosti, ako akesi zdelayovane streamy zmien (niekedy aj niekolko 10tok sekund po realnej udalosti).
Pod in-memory implementaciou ARC lezia teda nizsie vrstvy, a velmi zaujimava je druha vrstva.
Na tejto vrstve ma ZFS takzvanu L2ARC a ZIL.
L2ARC je level 2 adaptive replacement cache - cize akasi druha vrstva ARC a je to optional/toggleable feature. Admin moze priradit ZFS poolu L2ARC devices, ktore by mali byt rychle SSD (ie najrychlejsie storage devices v poole) a ZFS potom bude tlacit writes cez ne. Klasicke writes samozrejme prejdu az na VDEV layer, a do diskov, ale standardne ready sa tymto nastavenim daju akcelerovat cez L2ARC a tak tvori akusi "SSD cache". Strata L2ARC by v teorii potom nemala znamenat startu dat, ale len spomalenie read operacii poolu.
ZIL je ZFS Intent Log. Pre ludi prichadzajucich z XFS, JFS alebo EXT4 je to v podstate journal, ale na rozdiel od journalu v spomenutych FS (okrem teda EXT4 v data=journal mode, ktory sa najviac podoba na ZIL) kde tie ich journaly journaluju len a len metadata (inode number, props atime, ctime, dirents atd) a nie userdata (obsahy suborov), ZIL zurnaluje vsetko, cize aj meta aj userdata, ale len v pripade synchronnych zapisov (ie. ked aplikacie zavolaju sync()/fsync() zvycajne databazy pre durabilitu zapisov postgres, sqlite).
"Normalne" (teda asynchronne) zapisy (cize 99% zapisov na systeme) su automaticky "journalovane" transakcnou povahou ZFS, ale podobne ako pri zvysku klasickych filesystemov, system ma "pravo" ich vytlacit na disk az vtedy, ked uzna za vhodne. Cize ako sme naznacili vznika delay medzi bodom vyziadania zapisu v aplikacii a skutocnym zapisom na storage.
sync()/fsync() sycally vynucuju explicitny zapis, ale zaroven blokuju thread, cize aplikacny thread sa zasekne az do bodu, kym niesu data naozaj zapisane na najnizsie vrstvy. Synchronne zapisy su dnes najpomalsie zapisy ake system moze vykonovat. ZFS je urcene aj pre high performance databazy a tak ma proviziu na akceleraciu tychto zapisov.
Kazdy ZFS pool ma aj interny ZIL, ale pre zrychlenie (IBA(!)) synchonnych operacii, moze admin do poolu zase pridat SSD devices a presmerovat ZIL wrajty tam (je to dobre napr pre spomenute databazove stroje).
Osobne zastavam nazor, ze ak ide o rychlost, tak je jednoduchsie postavit cely ZFS pool na SSDckach. On-SSD L2ARC a ZIL maju vyznam len vtedy, ak ma clovek obrovske pooly s velkymi tocnami, a chce z nich (samozrejme len za urcitych podmienok) vymacknut near SSD performance.
Pod touto druhou vrstvou sa uz nachdza tretia, tzv. VDEV vrstva, ktora by sa dala v RAID setupoch (pozor ale, nepliest si, su tam brutalne odlisnosti) prirovnat k RAID striping. ZFS strajpuje writes cez VDEV-y.
Nakoniec samotne VDEVY, implementuju rozne redundancy politiky: zmirror, zraid1-3. Az tu vstupuje do rovnice 4 diskova vrstva, ktora riesi zapisy na realny storage.
A teraz Linux.
Ten disponuje io cache a dirent cache, zhruba podobnym ARC subsystemu ZFS. Pod tym moze byt md alebo LVM, co by sa dalo prirovnat VDEV a phys subsytemom pri ZFS.
Linux vsak dlhu dobu nedisponoval transparentnou read only SSD cache.
A prave tu implementuje bcache. Cize bcache je cosi ako L2ARC pre linux.
Clovek teda moze medzi md/LVM vlozit bcache a ziska tak akoby transparetnu SSD cache.
Osobne som nevidel velke vyuzitie bcache. Podobne ako ZFS L2ARC ma to vyznam len pri velmi velkych storage setupoch s pomalymi tocnami, kde clovek chce ziskat SSD level performance pre "hot" woking set.
bcache ma ale velmi zaujimavy a efektivny system organizacie tejto cache na baze BTREE.
Podobne aj v strede XFS, Reiser alebo ZFS je optimalizovany BTREE strom.
Po nejakom case prace na bcache, doslo viacerym ludom, vcitane bcache autora, ze by sa okolo daneho bcache coru dal postavat velmi vykonny a velmi lean filesystem.
A tak vznikol bcachefs.
bcachefs ma tak viac blizsie ku ZFS a BTRFS ako ku tradicnym fs minulosti.
Osobne mam pre tento fs velke ocakavania. Vidim ho ako vhobny hlavne pre VMky.
-
Mi bi se libilo, kdyby BTRFS umelo SSD jen jako read cache, tedy by nevadilo, kdyby se poksodil, nebot primarne by mel data na rotacnim raidu, ale jen casto pouizvane bloky mel na SSD, cimz by se brutalne zrychlila rychlost cteni, cache v RAM by byla vice mene hlavne pro zapis a vyupadek SSD by neposkodil data - mozna uz to ma LVM a ja to jen nesatudoval, nebot pouzivam primarne ent. diskova pole ...
Tam je to prav e ruzne, kdyz jsou full flash tak je jasno, SSD cahce soucasti raidu jsme vetsinou utlokli a kdyz se prezene IO a mnozstvi dat, tak je to zabije do te miry, ze je lepsi je nemit, nebot zpomelni ja nasbne pomalejsi nez kdyz tam SSD vubec neni - idelne kdyz to detekuje a prestane to delat - coz pak delal treba 3par nebo hitachi, kdyz tam prehazoval bloky velmi konservativne a pri pretizeni se na to vykaslal - aby preve nezabil spindle disky persouvanim dat mezi SSD a spindlem.
A pak treba infinidat, kde jsou SSD jen pro RO a tak co uz neni potreba se proste oznaci jako smazane, prazdne bloky, asi kasle na TRIM, ten je pomaly a na zapis ma RAM - ECC a servery/nody na UPS ... NetApp mel ve sve dobe flash cache, coz byla de fakto karta s kupou RAM a bylo to taky jen pro cteni, nebyla tak zalohovana baterkou, na rozdil od RAM - ono uz je dnes temer vse PC s linuxem nebo freebsd - stare karty melky RW cache s baterkou aby posledni zapisy zustaly a po obnove proudu se zapsaly na disky ...
Reseni RO SSD cache je ale velmi dobre reseni, nebot nejcasteji nejvice zpomaluje cetni, nebot tam se ceka na hlavicky, zatimco zapisy se de fakto sypou tam kde zrovna jsou bez ladu a skladu ;-)
U BRTFS je vyhoda, ze by to mohl umet prave FS ... a pokud by to bylo jen pro cteni, tak by byla temer jistat, ze nebude nicit data --- coz by u hot bloku, kde by se vse zapisovalo pres SSD nastat mohlo
-
Na necem podobnem pracuji - sparse mirror. Mas dve sady zarizeni - tj. HDD a SSD, kdezto to SSD je derave - "sparse", a slouzi primarne jako RO cache (rezim s write cache by vlastne znamenal tam mit dirty bitmapu), a pokud umre, nic se nedeje. Pri zapisu je treba samozrejme updatovat i to SSD.
Jak moc ta mensi ssd cache pokryva vetsi hdd pole zavisi na tom, ktere bloky se oznaci jako cachovatelne - primarni FS na hdd poli je EXT4*, takze mam cache bootstrap resen skrze zjisteni, ktere bloky jsou zajimave - vicemene to jsou systemove bloky (inody, bitmapy), adresarove soubory, a pak male soubory, nebo casti velkych souboru ktere obsahuji index (video) nebo nahledy (obrazky).
Sparsovitost bych rad ridil z userspace a mel to spise pod kontrolou, nez to nechat na systemu - tam ma smysl jenom hooknout fs driver, aby oznacoval nove vytvorene adresarove bloky jako cachovatelne. Ono se vlastne nic nestane, kdyz neco bude nebo nebude cachovatelne - rozdil je jenom v rychlosti nebo pak opotrebovavani SSD.
Netapp flash karty mam, to byl vlastne takovy predchudce NVMe :) Ale zajimavejsi jsou bateriove zalohovane RAM disky, taky pripojene skrze pcie - to muze slouzit jako neopotrebovatelny write intent log / zurnal. Ty novejsi co jsem mel, meli nvme api, a zapisy v radech PiB :)
* u EXT4 je disk layout primocary, na rozdil od chytrych FS ktere integruji raid/dedup/cow/snapshoty. Pokud bych mel neco podobneho resit na necem jinem nex EXT4, tak bych spis uz ohnul nfs cache, ktery cachuje na vfs urovni.
-
A ma to zmysel pri dnesnych cenach SSD/NVMe a rychlosti HDD riesit? Ja mam HDD namountovane na na klasicke velke veci ako videa, obrazky, ... archiv, ostatne je na NVMe. System so vsetkym SW sveta ktory potrebujete musite napchat do niekolko 100GiB (ja momentalne so vsetkym bordelom tam mam 193GiB) a tmpfs v RAMke:
tmpfs 1.6G 2.1M 1.6G 1% /run
tmpfs 7.8G 175M 7.6G 3% /dev/shm
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 1.0G 46M 979M 5% /tmp
tmpfs 2.0G 1.2G 832M 60% /var/cacheMne osobne nechyba absolutne nic.
