ZFS vs Btrfs

Naplózó filerendszerek (journaling)

Sziasztok!

Most hogy nagy ZFS lázban ég a fórum, a kérdésem az hogy ha az extra képességek nem kellenek, mindössze a snapshot képesség esetleg tömörített fáljtárolás és persze mindez stabilan, akkor milyen hátrányt jelent ha nem a nagyágyút (ZFS) vetem be, pusztán Btrfs-t?

Érdekelnek az előnyök, hátrányok. Például előny, hogy a Btrfs teljesértélű része Linux kernelnek, ez a ZFS és Linux kernel viszonyáról közel sem mondható el. De mi szól a Btrfs mellett és milyen esetben használjunk inkább ZFS-t Linux esetén?

( gyuri23 | 2019. 10. 11., p – 20:04 )

Nem kérdeztél egyszerűt, szvsz elsőre fusd át ezt: https://www.ixsystems.com/blog/open-zfs-vs-btrfs/

Én látatlanban a ZFS-re szavaznék, de ez erősen függ attól, hogy milyen gépen akarod használni. A ZFS sokkal kiforrottabb, sokkal többen használják, nincsenek megbízhatósági problémái. Van viszont erőforrás és tudás igénye. A linux kernelbe legnagyobb bánatomra tényleg nincs közvetlenül benne, de ez a CDDL licenc miatt van és nem a minősége az ok. Úgy tűnik ez is változik mostanában, mert a FreeBSD, Proxmox (meg még jopár) után az Ubuntu is belerakja a distrójába.
A Btrfs-t is használják páran, pl Suse, Synology de a RedHat most dobta a támogatását.

A btrfs snapshot-ról meg ez elég sokat mondó:
https://wiki.debian.org/Btrfs
Insure that the number of snapshots per volume/filesystem never exceeds 12; two or three times that might not cause ill effects, but keeping the count in the small double digits provides the greatest odds for avoiding morbid performance issues and out of space conditions. On the upside, many more btrfs snapshots can be taken before performance crashes when compared to LVM snapshots, where a single snapshot can introduce a performance crash.

A ZFS snapshot száma nagyjából korlátlan. Egy kolléga rekordja 500+ volt, mert azzal (is) mentett, és nem volt érezhető teljesítmény csökkenés a gépén.

Ez meg igen jó cucc: https://github.com/zfsonlinux/zfs-auto-snapshot

A btrfs wikijei nem mind frissítettek. A changelogokból jól látszik, hogy folyamatosan fejlesztik, többször láttam, hogy megjelentek benne olyan dolgok, amiket a wiki még úgy irt le, hogy még csak tervben vannak. Most úgy tűnik a hivatalos wiki oldala frissült egy nagyot, tehát lehet most valamennyire frissek az adatok.
Egy hibásan működő szkript miatt pár száz snapshot gyűlt fel egy szerveremen és semmilyen problémát nem okozott. A szerveren semmilyen lassulást nem észleltem. A backup rendszeren is kb 20-30 snapshot van megtartva, és soha nem volt észlelhető probléma.

Ebből a kategóriából nekem a kedvencem eddig (nagyon nem kerestem, de úgy éreztem diszkréten utánaolvasok mielőtt a backup-okat btrfs-re teszem):

" Using btrfs replace
When you have a device that's in the process of failing or has failed in a RAID array you should use the btrfs replace command rather than adding a new device and removing the failed one. This is a newer technique that worked for me when adding and deleting devices didn't however it may be helpful to consult the mailing list of irc channel before attempting recovery.
"

Forrás: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devic…

Lehet hogy RedHat dobta, de fedora a 32-s változatban integrálja teljesen.https://fedoraproject.org/wiki/Changes/BtrfsWithFullSystemSnapshots

OpenSusén semmi gond vele (itt teljes a funkcionalitással működik) és a Fedorán sem volt még vele gond. Igaz Fedorán alapértelmezetten nincsenek beállítva snapshotok. Sebességre 0 a panasz: compress=zstd,space_cache=v1

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

( akoscomp | 2019. 10. 11., p – 19:58 )

Olyan esetekben, amikor csak snapshot kell, én is btrfs-t használok, főleg ha az erőforrások is végesek, de nagy adatmennyiség esetén, ha szükség van replikálásra is, vagy távolra mentem az adatokat, akkor zfs-t.
Én kiforrottnak érzem a btrfs-t is. Már 5+ éve használom backup szerveren, és soha nem volt vele probléma. A zfs mindenben legalább egy picit többet tud, cserébe erőforrásigényes.

( micsa v | 2019. 10. 11., p – 20:21 )

ha btrfs-n snapshotot csinálsz, mindkettő (az eredeti és a snapshot) "él tovább" szabadon, azt csinálsz vele, amit akarsz, akkor törlöd le, amikor akarod.

zfs-nél ez nem így működik: egy dataset snapshotjából tudsz csinálni datasetet ("clone"), de nem lehet szabadon törölgetni, azt és amikor te akarod, mivel lehet "shared" data.

én is teljesen kiforrottnak érzem a btrfs-t, használom is sok éve, laptopon, home szerveren. még a compression is be van kapcsolva helyenként a laptopomon.

csak ugye nem megy a raid56... persze, lehet md/lvm alá tenni, de az már nem olyan...

zfs-nél ez nem így működik: egy dataset snapshotjából tudsz csinálni datasetet ("clone"), de nem lehet szabadon törölgetni, azt és amikor te akarod, mivel lehet "shared" data.

Snapshot-ot természetesen lehet törölni: zfs destroy pool/datasetname/name@snapshotname. Ha meg arra gondolsz, hogy magából a snapshot-ból törölni egy fájlt, az tudatos tervezési dolog, amivel 100%-ig egyet értek. Ha bele lehet nyúlni egy snaphot-ba onnantól kezdve az már nem snapshot.

Ha bele lehet nyúlni egy snaphot-ba onnantól kezdve az már nem snapshot.

de. feltéve, hogy úgy akarjuk.

csak úgy tűnik, te nem értetted meg a problémát:

van egy dataset, mypool/alma, annak 3 snapshotja, mypool/alma@1, mypool/alma@2, mypool/alma@3
én most akarok a 2-es snapshotról egy datasetet klónozni: zfs clone mypool/alma@2 mypool/korte
valamiért úgy döntök, hogy az egész mypool/alma-t le akarnám törölni...
és voila, nem lehet: "filesystem has dependent clones"...

Erre két megoldás is van. Az első a promote. A clone dataset függőségét leveszi a szülőtől, (pontosabban átcseréli, mert a szülő snapshot-jai is átmennek) átállítja clone-ból active filesystem-é. Utána törölheted a forrás dataset-et. A cone nem copy! Inkább tesztelésre van.
A másik lehetőség a send-receive (ami copy), mert itt nem is lesz függőség.

Nem egészen. Találtam egy elég érthető megfogalmazást:

ZFS snapshots are read-only pictures of the data they represent, so to make the data writeable you have to ZFS clone it. A clone is a fork in time from the data that existed in the filesystem from the chosen snapshot and it acts as a new filesystem with its own mountpoint.

A clone nem egy önálló dataset, hanem egy írható snaphot, amikor készíted tudomásul kell venni. Ha mégis az kell, jöhet a promote.

A send-recive-nél ha meg nincs elég hely akkor tényleg úgy jártál :)

erre az egyszerű esetre működik a promote.

ezt az esetet viszony nem tudom megoldani:
van mypool/alma1, ennek az egyik snapshotjából lett klónozva a mypool/alma2, és ennek egy snapshotjából lett klónozva a mypool/alma3

nem tudom az alma2-őt és az alma3-at olyan sorrendben és úgy promote-álni, hogy az alma1-et le lehessen törölni...

ötlet?

btrfs-vel teszem, veszem, törlöm a subvolume-okat, backupok, backupok visszaállítása, tetszőleges sorrendben.

egyszerű példa: update előtt (rolling distro), mindig van snapshot a root fs-ről. de bármelyik snapshot-ba be tudok bootolni (nem, nem akarok előtte parancsokat kiadni, csak ki akarom választani a grub menüben a snapshotot és boot). és a snapshotokat nyilván, törlöm, általában a legrégebbit először. De 5-percenkénti, automatizált snapshot is van, ami megint bekavarhat.

vagy valamit ki kell próbálni valamelyik vm-ben, snapshot a subvolume-ról, utána kérdéses, hogy meghagyom vagy nem. de a tegnap is volt már egy ilyen meghagyom vagy nem snapshot...

ha a laptopom, amin dolgozok és a "rajta van az életem" élesnek számít, akkor éles. amúgy meg nem, mert sokféle inkrementális backup van róla és nem szakad le az ég, akkor sem, ha meghal benne az ssd.

a send-receive nem erre van: akarná a túró megduplikálni a shared adatokat, így is alig férek a két 500as ssd-n.

most lehet azt mondani, hogy laptopra nem kell zfs... lehet, hogy nem kell zfs, de cow filerendszer kell. de szerveren is pont úgy kellhet tenni venni a subvolume/dataset-eket, pl. van egy rakás container, ha kell csinálni egy újat, nehogy már 0-ról konfigurálnám a debiant, általában klónozok egy meglévőt (vagy a snapshotját) és akkor úgy összevegyülhetnek mint a franc.

csak azt akartam ezzel mondani, hogy szerintem a btrfs design-ja egyszerűbb és általánosabb, mint a zfs-é, nem "skatulyáz" be annyira a konceptjei közé. az implementációja nyilván, olyan amilyen, de többnyire működik.

Ez most vagy kötözködés (nem olvastad végig a threadet), vagy ha esetleg tényleg nem érted, akkor ez az:
a fenti opcióval egy olyan másolatot csinál a fájlról, amely blokkszinten megegyezik az eredetivel (azaz nem foglal extra helyet az adat). Eddig olyan, mint egy hardlink.
Viszont copy on write, ami azt jelenti, hogy a hardlinkkel ellentétben a két fájl külön életet él innentől, azaz bármelyik a másiktól függetlenül módosítható, és csak azon blokkjai fognak változni (eltérni), amelyeket módosítottad.
Azaz ez egy írható, módosítható klón tulajdonképpen.
A zfs nem tud ilyet. A legközelebbi hozzá a bekapcsolt deduplikáció, de az sem teljesen ugyanaz, mert ott a fájlt be kell olvasnod, ki kell írnod, és a kiírt blokkokat checksum alapján köti majd hozzá a korábbi fájléhoz, ellentétben ezzel, ahol csak egy metaadat-művelet a másolás.

"csak ugye nem megy a raid56... persze, lehet md/lvm alá tenni, de az már nem olyan..."

Synology NAS-okon pedig így megy, egy pár éve pedig már a btrfs a default/recommended filerendszer.
Sok funkció (pl. virtualizáció) pedig kizárólag btrfs-el működik.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Ha jól értem a Btrfs-re írtad a lomhaságot?

Itt egy teszt ami szerint a tömörítés és a space_cache használatától táltos paripa lesz.

https://www.phoronix.com/scan.php?page=article&item=btrfs_space_cache&num=2

compress=lzo,space_cache=v1

v2 kicsit macerásabb, ne lehet csak kikapcsolni, előtte törölni kell a cache-t

Ha jól olvastam ma már az lzo helyett inkább a ZSTD ajánlott. 

Zstd tömörítésről: 

https://www.phoronix.com/scan.php?page=article&item=btrfs-zstd-compress&num=1

Geekbench teljesítmény összehasonlítás (ext4/btrfs) 

https://browser.geekbench.com/v5/cpu/compare/529846?baseline=543367

Ami a lényeg megszűntek a szerintem ext4 használata mellett tapasztalható anomáliák.

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

( locsemege v | 2019. 10. 12., szo – 16:11 )

Sőt, ha jól tudom, az LVM is tud snapshot-ot, s akkor azon lehet akár ext4 is.

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

Meg sotebb egy ideje tud az LVM is thin volume-okat is, ahol nem kell megmondanod elore, hogy mekkora legyen az irhato snapshot merete, hanem a kulonbozo thin volume-ok egy kozos pool-t toltogetnek. Hasonloan a btrfs snapshotokhoz es a cp --reflink=always -hez ezeknek is "nulla ido es nulla hely" a letrehozasa es szabadon torolgethetoek barhogy is epulnek egymasra.

Azért a thin-nel csak óvatosan. ProxMox szereti ilyenre tenni a VM-eket - azért volt pár meglepetés belőle.
- gyanús hogy a háttérben tömörít is. Ami tény: VM-ből a ProxMox alapgépen sikerült akkor load-ot elérni amikor a VM intenzív diszk IO-t tolt, hogy öröm nézni. A VM-ben a lemez írás sebessége ennek megfelelően elhanyagolható volt...
- a nyomorultja tud olyasmit is, hogy overprovisoring vagy mifene. A lényeg, hogy 1TB-s thin köteten simány gyárhatsz összesen 1.4TB-t foglaló köteteket, mert az az alapállás, hogy úgy sem használod egyszerre az egészet. Viszont ha erre nem figyelsz oda, akkor érhetnek olyan meglepetések, hogy bár giga-hegyek vannak szabadon, mégsem tudsz írni, mert hiba történt. Az alapgép naplóban látod csak, hogy elfogyott a tényleges szabad hely.
Szóval jó dolog a thin, de nekem nem jött be.

> - gyanús hogy a háttérben tömörít is

Alapbol biztos nem, mastol lehetett. (Pl. tanyeros HDD-n sok COW miatt "fragmentalodott" block device)

> - a nyomorultja tud olyasmit is, hogy overprovisoring

Ha pool szinten kezben tudod tartani a kihasznaltsagot, akkor szuper hasznos, szuper rugalmas. Erre ugyanugy kell figyelned ZFS es Btrfs eseten is (snapshotok, cp --reflink=always, ...)

( hunti v | 2019. 10. 18., p – 21:20 )

Úgy rémlik red hat kidobta a kernelből btrfs-t.

Félreértettem. Azt hittem, arról lehet szó, hogy a vanilla forrásából dobták a btrfs támogatást. Azért nem zavart ebben a kontextusban a Red Hat, mivel jócskán van ráhatásuk a kernel fejlődésére. Tehát akkor csak annyi történt, hogy az RHEL-hez fordított binárishoz úgy konfigurálták a kernelt, hogy sem statikusan, sem modulként nem tették a saját kernelükbe.

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

Rhel 7-ben volt csak benne, ott is csak preview-kent.
Kesobb onnan is kikerult, illetve 8-ba nem kerult bele.
Nem kell sokat belelatni csak azt hiszem osszesen 1 fejlesztojuk volt btrfs-re aki csinalta rhel kernelbe backportolgatasokat, ami igy nekik a hosszu support ideju verziokkal nem fer bele, ellenben xfs-re joval tobb kernel fejlesztojuk van.
Suse pl tovabbra is kiall a btrfs mellett es fejleszti.

( lajos22 | 2019. 11. 07., cs – 09:51 )

Nálam a btrfs az elmúlt 2 évben 3x borult össze puszta kikapcsolástól (laptop, lemerült az akku és nem volt ideje rendesen leállni), teljes adatvesztéssel, mert a hozzávaló repair tool egyszerűen csak wipeolt mindent javítás helyett.

ZFS-t nem próbáltam.

openSUSE Leap 15