A Bcachefs fájlrendszer beolvasztásra került a linux-next kernelfába

Fájlrendszer, NAS, storage

Bcachefs - "A COW fájlrendszer Linuxhoz, ami nem eszi meg az adataidat". Jól hangzó szlogen. A nagyra törő Linux fájlrendszer jó ideje keresi útját a mainline Linux kernelbe, eddig kevés sikerrel. Most viszont egy lépést tett előre: beolvasztásra került a mainline kernelfa előszobájának tekinthető linux-next kernelfába.

Emlékeztetőül a Bcachefs főbb tulajdonságai:

  • 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

( Botond | 2023. 09. 19., k – 08:36 )

"COW fájlrendszer Linuxhoz, ami nem eszi meg az adataidat"

Mert a ZFS, vagy Btrfs megeszi?

( zaphodb v | 2023. 09. 19., k – 08:49 )

Érdemes megemlíteni, hogy Kent Overstreet bár tapasztalt Linux fejlesztő, mégis meg kellett vele küzdeni, hogy a standard kernelbe bekerülés lépéseit végigcsinálja és mielőtt bekerült a linux-nextbe akkor egy rakat hibát ki is dobott az automata teszt.
https://lore.kernel.org/linux-bcachefs/

nincs aláírásom

( nevergone v | 2023. 09. 19., k – 10:16 )

Jó lenne egy olyan összehasonlítás, hogy (ezt is beleszámítva) melyik Linuxos fájlrendszer hova és mikor javasolt, illetve milyen esetben célszerű kerülni a használatát.

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

Az XFS pár százalékkal általában rosszabb a teszteken, mint az ext4. Ha jól tudom, bootolni nem lehet róla és az online shrunk sem működik. Amiben meg többet tud (pl. 8 EIB max kapacitás 1 EIB helyett, vagy nagyobb Xattr space) ott halandó ember nem ütközik az ext4 korlátaiba sem. De igen, az XFS jó alternatíva Linuxos fájlrendszernek.

 

A többi, mondjuk néhány évvel ezelőtti tapasztalat alapján, nem biztos, hogy ma is igaz:

ZFS: a metaadatokban keletkező bithiba, amit ext4-en fsck javít, itt a komplett pool eldobását jelentheti. Emiatt ECC védett RAM nélkül orosz rulett.

Btrfs: nem tudod a fájlredszert elindítani degraded módban (például RAID-1 -et 1 diszken). Van eszköz rá, hogy az adataid kimentsd, de azért na

A speciálisan mobilon vagy RAM-ban használatos fájlrendszereken kívül van még más általános?

Nem kell, hanem csak erősen ajánlott. Ha kellene, kötelezően, akkor el sem indulna nélküle, hanem leállna hibaüzenettel. De nem ez a helyzet.

Zfs and ECC myth (sokan írtak már erről): 

https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/

XFS: Valamikor nagyon régen volt az, hogy bootolni nem lehetett (biztonságosan) róla, de ez már nincs így. legalább 10 éve arról bootolok (grub, grub2 kezeli gond nélkül). Online shrink az lehet nincs, expand van, azt használtam már. Shrink régen nem volt, nekem meg nem kellett sosem, szóval nem tudok hozzá szólni, hogy ebben van-e változás.

Ezen a pályán még a reiserfs mozgott, az nekem valamiért sosem volt szimpi, és már nem is támogatott, de sokan anno azt preferálták. Illetve a jfs, de arról nincs tapasztalatom, talán még sosem találkoztam vele meg olyannal sem aki azt használná :) Más journaling fs tényleg nemnagyon játszik (oké, mondjuk az ext3 :) ), de az általánosba még belefér az ext2 meg így az ssd-k korában az f2fs is talán.

Stabil, élesen használt linux fájlrendszerek:

  • ext4
  • xfs
  • btrfs
  • zfs

A hozzászólások közt szerepel még a reiserfs, de az évek óta elavult, ki is került a kernelből. A jfs szintén elavult, bár még támogatott és valószínű van még pár elavult, speciális célra fejlesztett fájlrendszer, amivel általános használat esetén nincs minek foglalkozni.

Jó külön választani fs választás esetén a desktop és szerver szempontokat. Szerveren belül sem kell többnyire ugyanaz az fs-t választani az adattárolásért felelős partíciónak és az os partíciónak.

Megpróbálom összehasonlítani őket, de ez csak saját vélemény:

Az ext4 és xfs stabil, jorunaling fájlrendszer, aminek köszönhetően elvileg elég jól tűrik a hard reset-et. Ezen túl nem tudnak túl sokat. Az xfs több ponton, főleg szerver oldali szolgáltatások terén többet nyújt mint az ext4, pont ezért a RHEL alapértelmezett fájlrendszere. Önmagában szerintem egyik sem felel meg szerver fájlrendszernek, mivel alap dolgokat nem tudnak: compression, snapshot, encryption. Ezek a hiányosságok miatt én legacy jelzővel illetném őket.

Ezeket a hiányosságokat LVM és más eszközök segítségével lehet pótolni, úgy ahogy a redhat is teszi. Ezeknek köszönhetően főleg az xfs, jól használható komolyabb adattárolásra is. Az xfs egy jelenősebb előnye a több partíció támogatás.

Desktop esetében nem hinném, hogy bármelyik jelentősen többet tudna nyújtani mint a másik. Szerver os esetén szintén. Ha feltétlenül muszáj ezeket használni adattárolásra, akkor nagyobb IO esetén az xfs előnyei előjöhetnek, ezért az ajánlottabb.

 

A btrfs és zfs az már egy új szint. Mindkettő COW fájlrendszer, mindkettőben megtalálható a snaphost, raid és compression, a zfs-ben az encryption is. De a két fs mégis teljesen más szint.

A btrfs egy szerény, könnyen használható, kis erőforrásigényű, egyszerű toolset-el felvértezett fájlrendszer. Emiatt én kisebb mennyiségű adattárolásra (<10-20 TB), kisebb erőforrású szerverekhez tudom ajánlani, ha fontos az os (nem konténerizálva futnak a szolgáltatások), akkor root fs-nek is. A compression és a snapshot szolgáltatás életmentő lehet nagyon sok helyzetben. Ez a másik enterprise disztró, SLES alapértelmezett fájlrendszere.

A zfs egy igazi szerver fs. Mindent tud amit tudnia kell egy enterprise szintű adattárolásra szánt fájlrendszernek: compression, deduplication, encryption, raid, snapshot, checksum, cache device, stb. Hátrányaként említik, hogy nagy RAM zabáló, de ez relatív. Az fs úgy van megtervezve, hogy a kiolvasott adatok esetében cache-ként használja a RAM felét. Ez egyrészt nem egy kötelező feature, másrészt könnyen szabályozható, hogy mennyi ram-ot használjon. Ha storage-nak hasznájátok, valószínű az 50%-ot, 80%-ra állítjátok, ha desktop-nak, akkor simán le lehet vinni 10-20%-ra.

Az zfs-t semmi meg sem közelíti tudásban és a tudások kívül a toolset-je is nagyon komoly.

 

bcachefs - ezt nem használtam, nem ismerem a toolsetjét. A támogatott/támogatni kívánt feature-ok alaján a btrfs fölé helyezném, de valószínű nem fogja tudni megközelíteni a zfs-t. A célja, hogy olyan gyors legyen mint az ext4 és xfs, de a btrfs sem jelentősen lassúbb, bár tény, hogy általában ő az utolsó, de átlagban ez kb -10%ot jelent.

 

A fenti összehasonlítás főleg általános adattárolásra érvényes, nem speciális esetekre. A teljesítményt szinte egyáltalán nem vettem figyelembe, mivel sokkal inkább a hálózat a szűk keresztmetszet, nem az ssd-k sebessége, főleg ha 10-20-ról beszélünk.

Én ezt a sorrendet állítom fel, ha szerver adattárolásról van szó:

  1. zfs
  2. btrfs
  3. xfs
  4. ext4

Desktop esetében főleg a home folder-hez jól jön a btrfs snaphshot, ha kritikus a teljes os kiesése, akkor akár root-hoz is, de ha mented az adataidat és pár évente 1-2 órát ha kiesik a géped nem okoz gondot, akkor mindegy mit választasz. Megfelelő beállításokkal az zfs is opció.

( ggallo | 2023. 09. 19., k – 11:30 )

A feature list alapján olyan, mintha forkolták volna a btrfs-t, hogy átnevezhessék. Pont ugyan azt igéri, és pont ugyan azt nem tudja stabilan...

Engem érdekelne a motiváció, hogy miért fejlesztettek egy új fs-t azonos képességekkel, ahelyett, hogy beszálltak volna a tudásukkal már meglévő, ilyen képességet ígérő fejlesztésekbe.

Mert a cache-elés nem az a réteg. Semmi köze az fs-nek ahhoz, hogy a kernel hogyan manageli a hardware erőforrásait, a memóriát, mennyit, s hogyan cache-el. Majd eldönti a kernel, van-e erre elég RAM-ja. Az fs-nek az a dolga, hogy addig kitalálja, a filerendszer elejétől kezdve milyen offsettel tároljon adatot vagy hozzon el. Már ahhoz sincs köze, hogy van-e alatta LVM, RAID, bármi, egyáltalán van-e partíciós tábla. Ha a cache-elést az fs próbálja managelni, az rétegeken való átnyúlás, ami kerülendő. Persze csinálnak ilyesmit máshol is, például video tekintetében mindenféle direct-X, meg effélék, általában nem is szokott jó vége lenni annak, amikor egy alkalmazás bugja miatt az egész gép beleáll a földbe.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

a bcache-bol jott. vagyis abbol a regi-otvar "cache-eljuk ssd-n a hdd-t" izebol. valszeg nem tul nagy munkaval megoldotta, hogy rendes fs is legyen belole.

hogy mire jo? fene tudja. en f2fs-t hasznalnek igazabol szivesen, de nem annyira, hogy emiatt idot pazaroljak a linux install-nal, mert azok tipikusan nem tamogatjak.

amugy minden fs masban eros. el tudok kepzelni olyan io pattern-t, amiben ez jon ki legjobbnak es ezt valasztjak.

archinstall-lal tudsz f2fs-re telepíteni rendszert. Ha akarod megpróbálhatod. Nekem nem jött be anno az f2fs, de kb. 5 éve használtam, akkor még gyerekcipőben járt (volt egy trimmelési bugja), azóta sokat fejlődhetett sebességben és megbízhatóságban.

A bcachefs-t nem próbáltam még, és nem is gondolom, hogy ilyen túl fiatal fs-nek megadjam-e még az esélyt. Általában nem nyerő ötlet kiforratlan fájlrendszerrel szórakozni. Persze, ha a kernelbe kerül, ki lehet épp próbálni, nem kritikus rendszer alá root fs-nek talán nem túl kockázatos, ha van mentésed, vagy nem bánod az újratelepítést.

“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.”