Vlákno názorů k článku
Linus Torvalds má výhrady ke kódu Bcachefs pro 6.9
od RDa - Chtelo by to clanek, na porovnani btrfs /...
-
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.
