A Bcachefs fájlrendszer beolvasztásra került a 6.7-es Linux kernelbe

Fájlrendszer, NAS, storage

Előzmények:

A bcachefs főbb jellemzői:

  • Copy on write (COW) - like zfs or btrfs
  • Full data and metadata checksumming
  • Multiple devices
  • Replication
  • Erasure coding (only feature not quite stable)
  • Caching
  • Compression
  • Encryption
  • Snapshots
  • Scalable - has been tested to 50+ TB, will eventually scale far higher
  • Already working and stable, with a small community of users

Részletek itt.

( ggallo | 2023. 10. 31., k – 11:53 )

Engem érdekelne, hogy production környezetbe be merné-e valaki tenni az itt jelenlévők közül ennyi alapján (hogy bekerült a mainline kernelbe).

Azért ez az "Already working and stable, with a small community of users" nem győz meg 100%-osan...

Nagyon jól jönne a gyors CoW snapshot kombinálva a klasszikus user/group quota támogatással. A btrfs és a zfs nem támogatja a sima linux quota kezelést sajnos, így kézzel kell varázsolgatni ilyesmit, nem "integrálható" a meglévő, linux quota rendszert használó helyekre egyik sem könnyen.

Egy sima KKV-s Samba szerveren nagyon hasznos lenne manapság, ha lenne gyakori, gyors, helytakarékos snapshot (ransomware védelem egyik vonala gyanánt), de egyszerű lenne a kvótákat kezelni e mellett.

> be merné-e valaki tenni

hat en biztos nem... anno a btrfs-el is evekkel a kernelbe kerulese utan kezdtem el itthon kiserletezni egy ssd-n, de elegge furcsan mukodott, meg felig se volt a disk adattal de mar dobalta a 'out of disk space' hibakat, idonkent kezzel kellett rebalance-ot futtatni stb. aztan el is szalltak rola az adatok, szerencsere nem volt fontos.

ma mar nagyjabol mukodik, de azoat eltelt legalabb 10 ev hogy bekerult a kernelbe...

ransomware tipikusan 1-2 honapot, de akar tobbet is var, szoval snapshot nem fog vedeni.

pont azert varnak sokat, hogy mar backup-bol se erje meg helyreallitani.

Hiaba a kivalo backup, atlagos cegnek 3 honapnyi kieses mar majdnem olyan, mintha teljesen kiesett volna.

Ami inkabb segit, az a consistency check backup kozben: ha sql dump-ot backupolsz, akkor annak sql dump-szeruen kell kineznie; ha log-ot, annak log-szeruen. Ha valami gyanus -> visit. inkabb legyen 10 hamis riasztas, mint egy ransomware bejojjon.

Nem pontosan ertem, hogy mukodik ez a kivaras, de ket otlet a detektalasra:

1. Vissza kell allitani a backupot periodikusan, es ellenorizni a mukodeset (ez nyilvan nem olcso vagy egyszeru)
2. A dumpolt adatot tomoriteni kell (egyebkent is). Ha a tomoritett meret/eredeti meret arany tul nagy (szokatlan), akkor gyanithato a titkositott bemenet. (szemben a logokkal, sql dump-pal, amik szepen tomorodnek)

2.-ra: office fileok (az X veguek legalabbis) zip-ek, azon mar nem tomoritesz. se a png/jpg-ken. a pdf-en lehet egy keveset, de a nagyobbak ott is a beagyazott jpg-tol nagyok (scannelt cuccok)... raadasul van olyan ransom ami nem az egesz filet titkositja hanem csak az elejet, igy gyorsabban halad es az eredmeny ugyanaz.

akkor mar tobb ertelme van egy file validatort raengedni ezekre.

log-ot, sql dumpot meg eleve tomoriteni szoktuk rotalaskor.

hat nemtom, ha en gonosz lennek, akkor ugy csinalnam, hogy nem sima aes cbc -vel, hanem okosan: pl. ott a 3GB-os sql dump, oke, felvag 4096 byte-os darabokra, es azokat egy kulccsal generalt sorrendben ir ki. ha ugy tetszik, egy bonyolultabb pszeudorandom.

A fajl nem valtozik meg lenyegesen, tomoritve kb. ugyanakkora, sot, meg egy file-tipus teszt ellenorzesen is atmenne, csak eppen teljesen hasznalhatatlan, mert senki se fog egy gigabyte-os file-t 4k-s page-enkent osszerakni...

hiaba var a ransom, ha addig nem titkositja a fileokat, nem szamit. amugy miert varna? az adathalaszok szoktak varni, de az mas.

nalam a fileszerverek rsync-elve vannak egy masik szerverre (lehetoleg offsite), backup opcioval (rsync elrakja az elozo verziokat is), es errol megy egy napi log email, a valtozott fileok listajaval. ha gyanusan sok akkor meg kell nezni wtf tortent...

Igazából ez a "vár hónapokat" akkor érdekes, ha komplett image-ek vannak mentve bare metal recovery-re (vagy VM-ek kompletten olyan környezetben). Mert akkor a mentésben is már rég óta benne lehet a kártevő, ami a mentést visszatöltve újra akcióba léphet.

Vármi pedig azért szoktak, mert az első lépés, hogy valahogy bejuttassák a kártevőt, ami aztán adatot gyűjt vagy hozzáférést biztosít, és a valódi cselekvés előtt minél jobban feltérképezik az infrastruktúrát, próbálnak mindenhez is további hozzáféréseket szerezni. Ez pedig idő. Aztán a tényleges támadást akkor indítják, amikor a lehető legtöbb felületen tudják egyszerre csinálni, hogy jó nagy legyen az eredményesség, mire észreveszik.

Ha valaki csak (adat)fájl alapú mentést csinál, abban nagy valószínűséggel nem lesz működőképest ransomware, ami aktivizálódással fenyegetne visszatöltés esetén.

mar vegigragtam magam par ilyenen, mert anno eleg komoly etikai dilemma volt, amikor a holland korhaz rendszeret tamadta ransomware, hogy etikus-e megis fizetni.

vegul nem fizettek, hanem atvittek a betegeket mashova es ujrahuztak mindent.

ahogy mukodnek, az az, hogy eloszor csak behatolnak, es lassan, LASSAN, hogy ne keltsen gyanut, geprol gepre haladnak. Nyilvan egy massziv portscan 15 kulonbozo geprol triggerelne az intrusion detection system-et (igen, van ilyen, lehet venni penzert).

Ha megvan sok szerveren root, akkor elkezdenek transzparensen encrypt-elni. backup szervert kiiktatjak, vagy szemetet adnak neki. Elotte mar megneztek, hogyan megy a backup, es ahhoz igazodnak.

Amikor mar biztosak abban, hogy tobb honapnyi adat veszik el, ha nem fizet az aldozat, akkor csapnak le.

 

Igen, ez egy minimum 3, de inkabb 6 honapos kokemeny melo. Nyilvan scriptelik, amit tudnak, meg valszeg nem minden rendszert/0day-t/backup megoldast ismernek.

Aztan a valtsagdij annak fuggvenye, hogy mekkora a ceg (server/workstation szama). Ilyen 10-50 millio euro szokott lenni nagyobbaknal (1000+ workstation felett).

mar az is eleg lehet, ha beferkozott "virus" bekerul a backupba. igy a titkositas utani "allitsuk vissza a multheti backupot!" semmit nem er, mert az adatokkal egyutt visszallitjak a virust is, ami meg ujra lekodol mindent is.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Hát, a CoW snapshot lényege, hogy gyakorlatilag azonnal elkészül, és nagyon kevés hely kell neki (nyilván állományok változási gyakoriságától és mértékétől függően kevés), így rettentő sok megtartható belőle, és majdnem tetszőlegesen gyakran hozható létre. Akár hónapokra, évekre visszamenően ott maradhatnak, akár óránként vagy sűrűbben létrehozva (a tárhely forgalmától/igényektől függően).

A nagy tároló és backup gyártók modern ransomware védelmének egyik alapja ez a módszer, csak nem kötik a felhasználó orrára, hogy pontosan mi történik a háttérben, és mennyi a megőrzési idő.

Ha pedig a snapshot-ot tároló host-hoz nem férnek hozzá root jogosultsággal (ez azért elég jól védhető egy fájlmegosztáshoz képest), akkor maga a snapshot nem törölhető, nem változtatható meg (pláne távolról, megosztáson át). Ellenben azonnal hozzáférhető, még csak a backup-ból visszatöltést sem kell kivárni, és ez az óriási előnye. Ráadásul a ~0 elkészülési idő miatt sokkal gyakoribb lehet, mint a klasszikus backup-ok - így csökken a ténylegesen elvesztett adat mennyisége.
Meg mellesleg olyant is tud, hogy sima Windows desktop-on látszanak a snapshot-okban lévő különböző példányok, mint "előző verziók", és a felhasználó is vissza tudja tölteni saját magának (pl. elrontota, rámentett hülyeséget, stb.).

Persze a snapshot nem backup, azt a snapshot mellett is minden jóérzésú üzemeltető csinál onsite+offsite, 3-6-9-12 hónap megőrzéssel ügyféltől függően. Nyilván ha egy állományon csak egy hónap múlva tűnik fel a titkosítás ténye, akkor az egy hónappal ezelőtti, még éppen jó állapot megfelelő lesz, nincs adatvesztés. A napi használatú, fontos dolgokról meg gyorsan kiderül, hogy baja van.

Meg lehet találni azt a pontot, ameddig a snapshot-nak érdemes visszanyúlnia, és az annál régebbi dolgok meg jöhetnek vissza backup-ból. Vagy fontosság szerint lehet kombinálni a technológiákat. De ez már ügyfél függő, nincs egyetlen tuti megoldás.

Szerk.: sokan a snapshot-ot a VMware fél szörnyűséggel azonosítják, ami lassú, baromi sok helyet igényel, és nem szabad hosszan megtartani, mert belassítja a rendszert és megeszi a szabad helyet a host-on. Na, a rendes snapshot nem ilyen.

Hát, én főleg ZFS ismereteim/tapasztalataim alapján írom amit írok, amit mindenki CoW rendszernek hív, de a valóságban az általad említett RoW módszert használja. És az eddigi olvasmányaim alapján manapság minden ilyen rendszer a RoW módszert érti CoW alatt.

Az eredeti CoW valóban erőforrás pazarló a plusz olvasással és dupla írással. De végül is maga a CoW kifejezés a RoW működésre is ráaggatható, mert valójában az adat egy másolata kerül írásra itt is, csak épp nem az eredeti módszertannal (új helyre, már módosítva, és az eredeti helye vagy felszabadul vagy megmarad attól függően, van-e még rá hivatkozás).

Teljesen másképp működik és viselkedik az LVM thin és a ZFS snapshot annak ellenére, hogy végülis CoW működésű és gyors mindkettő.

ZFS esetén az egyes snapshot-ok egymásra épülnek (lineáris az egész), és az előző snapshot-hoz képest változott blokkokat tartalmazzák. Így az aktuálisnál kettővel vagy többel régebbi állapotot visszaállítani csak az adott snapshot klónozásával vagy az újabbak eldobásával lehet. Viszont blokk szintű és nagyon gyors, helytakarékos a módszer.

LVM snapshot esetén készül egy új LV, ami indulásakor az eredeti LV tartalmára hivatkozik, és az ahhoz képest változott blokkokat gyűjti onnantól. Itt viszont nem csak az utolsó snapshot állapothoz képest, hanem az eredeti LV-ről is készülhet további (bármennyi) újabb snapshot, ami szintén a készítése utáni változásokat gyűjti majd. Így lehet az eredeti LV-ről több, teljesen működőképes, egymástól független verzió is. Tehát fa struktúrába szervezhetőek a snapshot-ok, nem kötelezően függnek egymástól sorban.

Az LVM thin annyit ad ehhez hozzá, hogy nem kell előre jól méretezni (vagy menet közben átméretezgetni) az új (snapshot) LV-t, hanem az automatikusan hízik az igények szerint. A Proxmox pl. azért enged csak LVM thin-en snapshot-ot, hogy ne kelljen a nem-thin LV betelésére figyelni sem a rendszernek, sem az üzemeltetőnek.

Ezekből nekem csak ZFS-sel van tapasztalatom, azt használom sok helyen, a másikat csak így leírás szinten ismerem.

Abba még én se merném, pedig én szeretek kísérletezni, még a fő desktop rendszeremen is (anno, évekkel ezelőtt is bepróbáltam a Btrfs-t és a f2fs-t). Ez a bcachefs még túl új, túl kezdeni fázisban van. Lehet jó lesz ez, de én még várnék vele. Max. virtuális gépen, tesztgépeken próbálgatnám maximum. A fájlrendszerek amúgy is az a műfaj, amit az ember nem adoptál annyira sebtében, meg nem cserélgeti, mint a gatyát. Főleg nem adatpartíciók alatt.

Egyébként annyira szar máris nem lehet, ha Linus belement, hogy a kernelbe kerülhet. Egyszer biztosan ki fogom próbálni, de egyelőre még a stabilabb fájlrendszerek között is van, amit sose próbáltam (JFS, Reiser), és van, amit próbáltam, de nem fő rendszer alatt, hanem csak tesztrendszeren (XFS, ZFS). Legközelebbi rendszer-újrahúzásnál XFS-t tervezek először, majd JFS-t, így el fog telni jó idő, mire ez a bcachefs esélyt kap. Hacsak nem olvasok róla valami nagyon szenzációsat, hogy annyival gyorsabb meg kacsalábon forgó.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Én se erőltetném. A Phoronix tesztje alapján a sebessége botrányosan rossz a bcachefs-nek. Valahol érthető, még kezdeti kód, nem sok optimalizációt kapott, míg a bejáratott fájlrendszerek kerneldrivereit már évek, évtizedek óta optimalizálják, ezt nem lehet egy egyszemélyes projektnek behoznia pár hét-hónap alatt.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( nevergone v | 2023. 11. 04., szo – 02:43 )

Számomra még mindig rejtély, hogy miért nem a btrfs-be csatlakoztak be inkább? Sokkal előrébb lenne a történet.

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.