Btrfs vagy inkább maradjak az Ext4-nél?

 ( SySERR | 2017. május 25., csütörtök - 20:13 )

Sziasztok!

Nemrég átcsoportosítottunk pár gépet és az egyik gépből egy NAS lett összerakva benne 4*4TB diszkkel, mert a régi NAS hamarosan megtelik.
Ezen az összerakott NAS-on rendkívül vegyes tartalom várható és a fájlok darabszáma is igen nagy mennyiségű lesz. A megvágott videóktól kezdve a dokumentumokig szinte minden lesz. Lesznek rajta tömörítetlen RAW codeces videók is (pl. animációk, animált felirat alapok, stb…).
A fenti okok miatt merült fel, hogy érdemes lenne-e használni Btrfs-t tömörítéssel, vagy maradjak inkább a jól bevált Ext4-nél.
Itt most a gyakorlati tapasztalatok érdekelnek, hogy a Btrfs mennyire stabil, mennyire hibatűrő (áramszünet, RAM hiba esete stb…)
A gépen jelenleg Debian 8 van + SAMBA + NFS + FTP, és semmi extra. Az aktuális legújabb stabil kernel forrásból fordítva lesz még feltéve. Erről a NAS-ról egy másik kukázott gépen lesz mentés is.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Lekopogom, eddig nem borult össze btrfs-em (két desktopon használom, az egyik helyen némi szerver feladattal kiegészítve), van egy FS-em, ami túlélt bad sectoros vinyót, már egyik lemez sem az benne, amin eredetileg készült. Áramszünetet több ízben túlélt, RAM hiba még nem (vagy nem tűnt fel :) )
Amire figyelj, hogy ha kis, random IO-t csinálsz vele a fájlokon (adatbázis, virtuális gép image-k, ilyesmik), akkor ki fogja nyírni az IO-t a copy-on-write miatt (egy subvolume és nodatacow mount opció valamennyit segít rajta, de "érzésre" [nem mértem] arra a régi FS-ek jobbak).

Samba-nak viszont jót tehet, van hozzá btfs vfs modul (vfs_btrfs), ami bizonyos műveleteket gyorsít (ehhez mondjuk a kliens OS-nek és a programnak is támogatnia kell és jó műveleteket kell kérnie)...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Jelen állás szerint mezei dokumentumokat mentenek és írnak felül a kollégák. A videók nagy része meg csak tárolva lesz.
Tervbe van véve az is, hogy több gép erre fog loggolni, ami appenddel jár. Ez utóbbi mennyire problémás?

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

BtrFS-nél figyelni kell a CoW (copy on write) funkcióra, ugyanis ha nagy fájl kerül módosításra, akkor azt előbb lemásolja hogy ne legyen olyan időablak, amikor elveszhet a régi adat a módosítás közben. Ez a biztonsági lehetőség viszont nagy sebesség romlásba kerülhet. Javasolt például DB-k fájljain és virtuális képfájlokon is kikapcsolni. Viszont ha sok fájlon kell kikapcsolni, akkor ennek a menedzselése válhat kényelmetlenné.

Alapból lassabb kicsit mint az Ext4, de a plusz feature-ök jók. Nekem 1 éve stabilnak tűnik, mindennapos használatban van munkaállomáson.

nem az egész file-ot másolja át, hanem csak azokat a blokkokat, amik módosulnak.
Javasolt adatbázisoknál kikapcsolni a copy-on-write-ot, HA sok a módosítás, mert nagyon megfragmentálja a filerendszert és teljesítménycsökkenéssel jár.
De ha nincs sok írás, csak főleg olvasásra használják, akkor azzal sincs baj.
Én évek óta használok virtuális gépeket btrfs-n (laptopon, tesztelésre, most is van vagy 8)... ssd-n, igaz, de nem volt még bajom vele.
A nagy előnye, hogy ha kell, egy pillanat műve visszaállítani az 5-ercenkénti snapshotokból (elcsesződik a vm guest vagy valamit felinstallálok oda, hogy megnézzem, stb.)

Továbbá használok btrfs-t, ugyancsak évek óta inkrementális backupra (rsync + btrfs snapshotok, hdd-n), mindennap lebackupolja a laptopokat, a home szerver bizonyos részeit...
Itt elég nehéz elkerülni a fragmentációt, de ezzel sem volt még baj (s még csak nem is x86 :) ).

Vajon a snapshot-nál is csak a módosult blokkok másolódnak?

Snapshotnál nem másol semmit, csak megjegyzi az időpontot. Az ezután módosuló fájloknál csak a módosult blokkokat másolja.

Naná! :) - mármint +1 az előttem szólónak, nem másolódik semmi, csak ami változik (blokk szinten).

Más kérdés, hogy a snapshot ingyen van, de ha a snapshotból törölsz pl. tömegesen, akkor az ugye már írás lesz, tehát a törléstől alkalmasint fogy a szabad hely :D Persze a snapshot törlésénél minden le lesz takarítva.

AFAIK Appendnél nem okozhat gondot, legfeljebb ha töredezik, de az csak olvasásnál jön elő.

Image fájloknál ugye a gond az, hogy ha van egy AAAAAAA tartalmú fájlod, amiben a harmadik A-t cseréled egy B-re, akkor a COW miatt ez úgy fog kinézni, hogy kiír valahova egy B-t, aztán módosítja a fájl metaadatát, hogy az a B is benne van (tehát az AABAAAA helyett lesz egy AA[A]AAAA...B tartalmad a vinyón, de a fájlod tartalma rendben lesz), amikor viszont olvasni akarod a fájlt, akkor az első két A után lesz egy seek-ed valahova máshova, ami vinyón lassú. (brutálisan leegyszerűsítve és elferdítve a dolgokat)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Én több éve használom telefonon (Jolla1) és alapvetően nincs bajom vele, mondjuk többszáz file egymás utáni olvasásánál rettenetesen be tud lassulni. Ahogy itt olvasom ez a töredezettség miatt lehet. Ezekszerint ebben nincs autodefrag. Meg lehet ezt oldani viszonylag egyszerűen?

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

Van benne autodefrag. A probléma az az, hogy ha van egy snapshotod, ami az 'AAAAAAA' tartalmú fájlra mutat (az előző példával élve) és egy, ami az 'AABAAAA' fájlra, akkor azon nem tudsz mit defragolni, a frissebb verzió blokkjai ahogy "overlayelik" a régi verzióéit, mindenképpen töredezett lesz a frissebb 'AABAAAA' tartalmú fájl, (legalább) két helyről kell összefésülni a blokkjait.

Ha törlöd a régi snapshotot és felszabadulnak a hozzá tartozó blokkok, akkor az autodefrag szépen el fogja intézni neked, hogy az 'AABAAAA' már töredezettség nélkül helyezkedjen el a háttértáron. De amíg a régi snapshot "lefagyasztja" azokat a blokkokat, ezt nem teheti meg.

Ez a minimális idő- és tárhelyigényű snapshotok ára. Valamit valamiért.

Mondjuk ssd-n/flash drive-on/mobilon/pendrive-on/stb. ez nem kéne nagy gond legyen...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Egyelőre nem lesz olyan fájl rajta ami CoW-ot használ (DB, virtuális gépek, stb...). Ha esetleg később mégis lesz DB aminek nagyon kicsi az esélye, akkor simán megy fel a rendszerdiszkre, ami már most Ext4.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Akkor ok (egyébként pont fordítva: btrfs minden fájl CoW, kivéve, ahol explicit letiltod [nodatacow], mert kell pl. a snapshot-hoz, amiket felsoroltál azok azok, amiknél ez gondot okozhat)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> subvolume és nodatacow mount opció valamennyit segít rajta, de "érzésre" [nem mértem] arra a régi FS-ek jobbak

Sajnos subvolume-okra még mindig nem lehet egyedi mount opciókat adni, az elsőnél megadottak játszanak. Szerintem ezért is nem tapasztaltál különbséget. Lásd:
Most mount options apply to the whole filesystem, and only the options for the first subvolume to be mounted will take effect. This is due to lack of implementation and may change in the future.
This means that (for example) you can't set per-subvolume nodatacow, nodatasum, or compress using mount options.

Külön partíció segíthet, vagy chattr -tal is letilthatod a COW-t.

chattr +C /dir/file

Érdemes ezt könyvtárra megadni és akkor a benne újonnan létrehozott fájlokat már nem COW-val fogja kezelni.

Köszi, ezt jó tudni; kipróbálom este.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Sok éve btrfst használok itthon is, szervereken is. Én btrfst raknék. A btrfs compress nyugodtan mehet, a tömörítés ugyanis a metaadatoknál is számít, a nem tömöríthető adatokat meg valahogy detektálja, és nem próbálja tömöríteni (hogy cput spóroljon), szóval nincs hátrányod a compress kapcsolóból (tapasztalat szerint, nem benchmark szerint)

Hibatűrés: a btrfs metaadat és file adat szinten is checksumot tárol, és olvasáskor ellenőriz. Így ram hiba, hdd hiba, vagy bármi esetén van egy konzisztencia ellenőrzés. Természetesen ram hiba esetén az adatok megsérülhetnek a kiírás előtt is, ez ellen nem véd semmilyen filerendszer, de amennyire lehet, a btrfs jobban, mint az ext4.

Esetleges adat ismétlődésre ott a deduplikálás ( duperemove -r -v -d /mnt/x ).

Ott vannak a snapshotok, a file szinten állítható redundancia (kvázi raid), meta adatra szintén (bár ezt még nem próbáltam).

Recovery re is van tool, ami ér annyit, mint az ext4es katasztrófa esetére, de a backupot természetesen nem pótolja semmi.

Egy dologra a copy on write miatt nem feltétlen ajánlom a btrfs-t: virtuális gép imagek / nagy adatbázis fileok, amiken sok update van. Ebben az esetben az íráskor az image töredezik durván. Erre megoldás a nodatacow mount opció, amivel sajnos a checksum is kikapcslásra kerül, VAGY a(z online) defrag időnként az image / db fileokra.

A btrfs nél ott az online shrink, ami főleg ilyen nagy filerendszernél a jövőben még jól jöhet. Nem is egy fs-t csinálnék, hanem lvm-et, és azon külön fs-eket, ha ez megoldható.

A 4x4TB hdd mellé rakj még ssd-t is bcache el (lvm alá) és akkor nagyon jó lesz a teljesítmény file listázásoknál, meg random olvasásoknál.

Sok sikert!

"Az aktuális legújabb stabil kernel forrásból fordítva lesz még feltéve." - Debianon ezt mi indokolja? A btrfsnél sok fejlesztés van folyamatosan, de nem tudok olyan fícsörről, vagy fixről, ami miatt ez valóban fontos lenne (mondom úgy, hogy Gentoon én így csinálom, de Debianon nem erőltetném)

+1 főleg nem egy éles rendszeren. Nagyon macerás a kernel update így, meg baromság is már elég rég elég stabil a btrfs, felesleges emiatt szórakozni vele.

Eddig a forrásból fordított kernellel mindig gyorsabb volt a rendszer, különösen a boot. Ettől függetlenül minden esetben meg szoktam tartani a gyári kernelt is, tehát szükség esetén azzal továbbra is bootolható.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Elméletben is max. minimális lehet a különbség boot után, a boot lehet akár sokkal gyorsabb is de egy nasnál nem mindegy?

+1 lenne, ha Gentooról lenne szó, Debiannál továbbra sem érzem reálisnak, több a függőségekkel a szopás, mint amennyit ér a saját kernel. A gyorsabb boot az jogos (a sok autodetect miatt), viszont cserébe egyszer pont akkor nem lesz bootkor hálókártya driver egy másik gépben, amikor gyorsan kéne kiváltani a NAS-t stb. :D

Ha a futáskori sebesség, testre szabhatóság fontos, akkor viszont ajánlom inkább a Gentoot tényleg. :D

Pontosan ezért van megtartva a gyári kernel is ami bootolható, hogy még veletlenül se legyen akkor se gond ha a fél gépet cserélni kell. Amúgy még régebben pont a gyári kernellel jártam úgy, hogy az Intel e1000-es hálókártya drivere folyton telehányta a konzolt mindenféle hibaüzenettel. Egy Asrock lapnál meg a Realtek alaplapi hálókártya akadt össze az USB-vel ha az engedélyezve volt.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Egyébként pont a napokban cseréltem le a WinXP-t Debian 8-ra a súgógépen. Valami régi SiS chipsetes lap 1 magos CPU-val. Grafikus felület indulásakor azonnal megállt mint a szög. Fordítottam egy 4.11-es kernelt és azzal már ment is ahogy kell neki. Igaz, ez nagyon távol áll a szervertől, de jól mutatja, hogy egy új kernel néha csodákra képes :)

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Szerintem semmi gond nincs azzal, ha magad fordítod a kernelt, de ha jót akarsz, BTRFS-hez jó sűrűn kell majd ... :( (backportból!) a stable 102% felejtős...

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

A boot elhanyagolható. Mondjuk átlag hetente 1x van egy restart, akkot nyersz vele mondjuk 10 másodpercet, hetente. Számít ez?

Illetve : a btrfs már stable? Van már rá fsck? Van olyan mainstream LTS jellegű distro, aminél ez a default FS?
(Nem követem, szóval tényleg kiváncsi vagyok, nem fikázás miatt kérdezem.)

Suse jópár éve support-álja, ők voltak az elsők akik ajánlották emlékeim szerint. Bár azt hiszem nem default volt. Fsck van rá, használtam is:

http://paste.ubuntu.com/24660570/

Idézet:
WARNING: the repair mode is considered dangerous

velemeny?

Mint minden más fsck ami ír, magában hordozza a kockázatot, hogy mindenféle adat sérülést nem tud kezelni, és az eredmény lehet rosszabb, mint a javítás előtt. Másolat készítése javasolt!

BTRFS eseten nincs szukseged erre a tool-ra. Ez csak akkor kell, ha valami nagyon nagy gixer van es akkor amugy is az az elso, hogy backup majd kiprobal.

Idézet:
Van olyan mainstream LTS jellegű distro, aminél ez a default FS?

Valamennyire:

Idézet:
With SUSE Linux Enterprise 12, Btrfs is the default file system for the operating system, xfs is the default for all other use cases.

(mondjuk nekik szvsz. leginkább a snapper miatt kellett)
Szerk.: Forrás: https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Köszönöm (és log69-nek is persze). Nem követem a btrfs híreket, de az már jó jel ha egy mainstream distro rá meri bízni az adatokat.

Nem kell fsck mert self healing fájlendszer. Az fsck.btrfs semmit nem csinál (szó szerint), a btrfsfsck meg egy offline recovery tool.

A btrfs restore az offline recovery tool, csak a pontosság kedvéért. De ha arra szükség van, már régen rossz, előbb nyúlnék a backuphoz.

A stabilitást összefoglalva tapasztalat szerint van olyan stabil, mint az ext4 régóta. Az ext4el sokkal több probléma van, pl. amikor 50% szabad helynél insufficient space, mert elfogy az inode... A feature készletről meg már korábban írtam.

A conszisztencia ellenőrzésre meg

btrfs scrub start /mountpoint
btrfs scrub status /mountpoint

és a dmesgben ott van minden érdekes dolog, ha gond van. Többet ér, mint bármilyen offline fsck.

Synology nason 4x3tb data, shr-ben ( syno raid 5) btrfs-re formázva. Még hibát nem dobott, pedig van rajta virtuális gép.

Egyszer kipróbáltam, de dobnom kellett, mivel swap fájlt nem támogat. Azt írják, hogy:

Idézet:
Does btrfs support swap files?

Currently no. Just making a file NOCOW does not help, swap file support relies on one function that btrfs intentionally does not implement due to potential corruptions. The swap implementation used to rely on some assumptions which may not hold in btrfs, like block numbers in the swap file while btrfs has a different block number mapping in case of multiple devices. There is a new API that could be used to port swap to btrfs; for more details have a look at project ideas#Swap file support.
A workaround, albeit with poor performance, is to mount a swap file via a loop device.

Ez az egy swapos hátulütője van a btrfs-nek, amúgy szerintem jó fájlrendszer. 2 éve használom, nem volt vele adatvesztésem. Előtte ext4-nél áramszünet után indulgatott a fsck meg a torrentkliensben is elcsesződött a resume data, ez btrfs-nél nincs, simán éli túl az ilyen leállásokat. Sebességre ugyanott vannak, ha a btrfs-en nem kapcsol be az ember fia mindenféle funkciót. Ennek ellenére az ext4 sem rossz fájlrendszer, teljesen jó, ha valaki úgyse használja ki a btrfs többlettudását. Plusz ext4-hez hozzá lehet férni Windows alól is, míg btrfs-hez nincs ilyen tool.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

Meghibasodott memoria miatt szetfirkalta a teljes metat: https://www.spinics.net/lists/linux-btrfs/msg59566.html
Ezen felul ha SSD-d van, nincs backup metadata, ami logikusnak tunik, de ilyen esetekben pont jol jott volna.
A kod turasa utan sikerult visszafirkalonom, hogy az adatokat le tudjam menteni. Azota ext4 van a gepemen.

ECC nelkul en nem hasznalnam.

Meghibásodott memória ellen semmi nem véd, minél fejlettebbek a funkciók és minél többet gyorsítótáraz, annál inkább kell fs-től függetlenül. Na jó a ZFS meg lehet jobban checksumoz mindent, de akkor is.
Én most próbálkozok a BTRFS-sel a tömörítés miatt. A ZFS túl overkill lenne és majd szervergépen fog lenni VM-ben.

"Na jó a ZFS meg lehet jobban checksumoz mindent, de akkor is."

Btrfs is checksumol mindent, és olvasáskor ellenőrzi a konzisztenciát. Ha több példány van, akkor a hibásat ki is javítja jóra beavatkozás nélkül.

Az ellen nem ved ... de viszont ha lett volna alapbol backup tree akkor megsporolhattak volna nekem tobb napot.

Mitől overkill a ZFS bárhova?

Amióta linuxon is stabilan használható NAS-nak csakis ZFS-t használok.
zfsonroot az egyetlen scenario, amit még nem próbáltam, de lokális gépen fontos adatot már nem is tartok, csak nas-on, azon meg ZFS van + ECC memória benne.
Mint azt te is írtad, hibás memória ellen semmi nem véd.
Viszont az ecc+zfs páros a "csendes" hibák ellen killer kombó, és szerintem megéri.

Szerk.: Pontosítanék: régebb óta használok ZFS-t, mint hogy linuxon is stabil lenne. Bár az OmniOS sorsa most kétséges kicsit, hogy az omniti kivonul mögülle, de illumos kernel alapon is van még jópár rendszer.
Amit írni akartam, hogy mióta linuxon is van stabil zfs, azóta raktam már össze linux alapon is nas-t (Debian8) és ott is zfs-t használtam.

"Ezen felul ha SSD-d van, nincs backup metadata"

Már nem csak ssdn nem default a duplicate metadata, de mkfs nél megadhatod, hogy minden meta adat blokk duplikálva legyen, és akkor a meta adat block hash miatt elég nagy az adatbiztonság. Persze hibás rammal előbb utóbb gond lesz mindenképpen.

mkfs.btrfs -m dup ...

man mkfs.btrfs ből:

-m|--metadata
Specify the profile for the metadata block groups. Valid values are raid0, raid1, raid5, raid6, raid10, single or dup, (case does not matter).

A single device filesystem will default to DUP, unless a SSD is detected. Then it will default to single. The detection is based on the value
of /sys/block/DEV/queue/rotational, where DEV is the short name of the device.

Note that the rotational status can be arbitrarily set by the underlying block device driver and may not reflect the true status (network
block device, memory-backed SCSI devices etc). Use the options --data/--metadata to avoid confusion.

See DUP PROFILES ON A SINGLE DEVICE for more details.

Jah, amikor en kezdtem hasznalni nem igy volt ez ~3-4 eve kerult bele. Ha verbose modban inditod az mkfs-t akkor kidob egy warningot errol, amugy nem.

Eszerint: https://github.com/kdave/btrfs-progs/blob/master/mkfs/main.c#L1585 + az idezett man szerint is A single device filesystem will default to DUP, unless a SSD is detected.

Szoval, ha nem SSD akkor marad a DUP.

Nem használnád ECC nélkül? Oké. Mit használnál, ext4et, ahol SEMMILYEN ellenőrzés nincs a konzisztenciára? Mondjuk ott nem lesz io error, ha sérül az adat ram hiba miatt, csak simán kiolvasod a sérültet :D

ECC nelkul semmit. De ha nincs lehetoseg ra, akkor barmi olyat aminek a check/repair eszkoze nem segfaultol el egy nem vart helyzettol... (es azt mar nem hibas memoria okozta) Nekem kellett irnom egy primitiv kis programot, amivel manualisan helyrefirkaltam a dolgokat ...

Ezen felul, igen, jelen esetben jobb lett volna a serultet ugy kiolvasni, mint elvesziteni a teljes tree-t, bar tok jo volt, hogy miutan kijavitgattam, gyorsan ki tudtam kukazni a hibas fileokat.

A Btrfs-nél egyébként ezzel a tömörítéssel nálam az egyik előny pont a szerkesztőségben található mindenféle hulladékból összerakott gépeken jött ki. Van olyan gép amiben még Quantum lct 10Gb diszk van benne, a CPU viszont C2D, tehát elég érdekes :). A tömörítés miatt a rendszer olvasási sebessége teljesen jó, az adatok meg a NASokon vannak. Tehát innentől az se gond ha megpusztul a diszk, mert akkor egy másik hulladékra PXE boottal 5 perc alatt újrahúzom a rendszert.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Hordozható merevlemezen használok btrfs-t már vagy két éve. Volt, hogy menet közben lett lehúzva adatírás közben. Nem is egyszer. De soha nem volt probléma a btrfs-sel. Ext4 ilyen megpróbáltatásokat szvsz nem bírt volna ki hiba nélkül.

> Ext4 ilyen megpróbáltatásokat szvsz nem bírt volna ki hiba nélkül.
Kibírta volna.

De nem jobban :D

A 4*4TB diszket hogyan tervezed szervezni? RAID1, RAID5?

RAID10, de ez még nagyon képlékeny. Tesztelni lesz idő bőven, tehát ez még változhat.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

+1, vagy simán raid1. A raid5 nél lassú az írás, és a recovery is babrás, ha gond van. A pillanat, amikor 4 hdd ből 1 elromlik, de a resync nél beesik még1 io error és az egész raid használhatatlan és lehet mindenféle force megoldással recoveryzni... :D Még mindig jobb, mint az alaplapi vagy hw raidek, ahol még a formátum miatt se megy másik gépben pl. Valójában ha nagy rendelkezésre állás nem fontos (nas), akkor én az egyébként is elkerülhetetlen backupot venném redundanciának, és nem kell raid. Attól függ mekkora gond, ha kiesik pár órára a gép :)

raid6, és akkor bármelyik két diszk kiesését elviseli.

vagy raidz2 és akkor rendes fájlrendszere is lesz mellé! ;-)

+1, RAID6 vagy RAID1

Sakk-matt,
KaTT :)

RAID10 4 diszkkel veszélyes, én annó megszívtam. A következő miatt: A BTRFS-nek minden RAID szintnél van egy minimum diszk mennyisége, ez alatt nem tudod online-ba tenni, RAID10-nél ez 4. Másrészt nem támogatja a remove-add jellegű cserét, csak az add-remove -ot. Azaz ha 4 diszkből csinálsz RAID10-et ÉS elszáll egy diszked ÉS nincs +1 SATA csatolód, amire az új csere diszket felkötnéd, akkor az egyetlen módja az adataid kinyerésének az, hogy offline dumpot csinálsz egy másik eszközre (ez kb. olyan, mintha valahova kibontanál egy .tar.gz fájlt). Itt egy szál a problémáról. Ennek ugyan már egy éve, de nem láttam a doksikban, hogy ez változott volna.

Ha btrfs akkor a RAID5-öt felejtsd el legalábbis a btrfs-ét, de szerintem amúgy se egy túl jó ötlet.

Attól függ, hogy akarod-e a btrfs plusz képességeit használni. Ha csak egy jó fájlrendszer kell, extrák nélkül, akkor ext4. Kiforrott és nekem még semmi bajom sem volt vele. A btrfs sem rossz, nem vesztettem még vele adatot, sok kis fájlra ellenjavallt.

Sok kis filera is gyors a btrfs, talán ext4 nél jobb is a tömörítés miatt (meta adat tömörítés). De a valódi teljesítményt az ssd cache fogja szolgáltatni bcache-el sok file esetén.

Dehogy gyors. Egy emerge --sync (sok kis fájl rsync-je egy távoli gépről) látványosan gyorsabb ext4-en.
Elég nagy ssd gyorsítótárral minden fájlrendszer gyorsnak tűnik.. :)

ZFS miért nem játszik? Nálunk sok éve megy Linuxon probléma nélkül.

ZFS-sel nem nagyon volt még dolgom, de annak tudtommal nagyobb az erőforrásigénye is (RAM). Btrfs viszont már több kukába való desktop gépen bizonyított.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Nálunk HP N40L-en is teljesen jól teljesít, pár éve volt itt benchmark róla hasonló konfiggal. ECC RAM nélkül ne állj neki, megvan, hogy mekkora tárhelyhez mennyi RAM az ajánlott. RAID10 helyett raidz2-vel + SSD read cache (L2ARC) és write cache (ZIL) jobban járnál: bármelyik 2 disk kiesét is túléli, ellentétben a RAID10-zel.

Persze puding próbája az evés: nem tart semeddig sem kipróbálni, apt-get install bonyolultságú a telepítése.

ECC nélkül tönkremegy a ZFS, és az ext4 nem?

Nem.

Valóban pongyolán fogalmaztam.

Terjed egy olyan elmélet, hogy a ZFS scrubbing során, ha nem ECC RAM-od van, akkor a ZFS egy memória hiba esetén úgy érezheti, hogy a helyes adat korrupt, és felülírja korrupt adatokkal. Ugyanez bármely checksumolós / self healing fs-sel előfordulhatna elméletben, akár btrfs-sel is.

A másik oldala a dolognak, hogy ha jól tudom, ilyet még senki se látott ténylegesen megtörténni, de legalábbis nagyon ritka. Másrészt az is igaz, hogy _bármilyen_ más FS-nél (incl. ext4) nem ECC RAM-nál egy RAM hiba korruptá tudja tenni az adataid, és nem is jössz rá soha, csak ha használni akarod és nincs meg.

Idézet innen (a ZFS egyik első fejlesztője volt a Sun-nál): https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=26303271#p26303271

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

A lényeg az utolsó mondat szerintem.

Tehát sorrendben:

1. ZFS+ECC
2. ZFS
3. bármilyen más fs

Arról van valakinek infója, hogy notebookokban mennyire elterjedt az ECC RAM - ha egyáltalán - és hogy ez hogyan ellenőrizhető? Például egy "dmidecode -t memory | grep -i ecc" megmondja? Gondolom nem elég a memória modulnak ECC-snek lennie, az alaplapi chipset-nek is támogatnia kell. Jól gondolom?

Serveren nem Linuxot, desktopon meg nem ECC-s modulokat használok, tehát csak a második kérdésedre tudom a választ: igen, támogatnia kell a lapnak, sőt, a processzornak is.
------------------------
{0} ok boto
boto ?

Kösz.

A Dell-nek pl vannak workstation laptopjai ECC-vel:
http://www.dell.com/en-us/work/shop/productdetails/precision-m7710-workstation/xctomp771017us

Amúgy már régóta vannak akik szeretnének softECC-t látni a Linux kernelben, csak akik meg értenek hozzá, és le is tudnák programozni, azok szerint hülyeség, mert bűn lassú lenne. Pedig az igény megvolna.

Sajnos láttam megtörténni olyat, hogy ext2-t szétqrt a gépemben egy bithiba a ram-ban a boot során induló fsck...

Ha mar ajanlgatjuk otthonra ezt erdemes elolvasni nehogy utolag legyen meglepi:

http://louwrentius.com/the-hidden-cost-of-using-zfs-for-your-home-nas.html

tldr, össze tudnád foglalni mi a rejtett költség?

A software szar, mert csak hardware-en futtatható, amit nem adnak hozzá, pedig az ingyen volt. Emellett szar minden, ami egyetlen példánya elvesztésekor megszűnik létezni. Szar továbbá az, ami tervezést igényel.
------------------------
{0} ok boto
boto ?

Pl az hogy egy vdev -hez nem tudsz uj disket adni vagy csak siman lecserelni az egyik disket nagyobbra illetve ha masik vdev -et krealsz hogy ezt elkeruljed akkor a masodik vdev miatt diszket "vesztesz" a paritas miatt ami igy ket vdev miatt dupla annyi lesz. Magyarul jo elore kell gondolkozni mekkora tarhelyre lesz szukseged de akkor meg az is problema lehet hogy az egy nagyobb pool miatt tobb lemezt kell megvenni mint amennyire a start allapotban szukseged van.

Masik verzio hogy minden egyes lemezt kicserelsz nagyobbra a vdev -ben. Ez se nem olcso se nem egyszeru mert csak egyesevel tudod megcsinalni. Replace aztan resilver megint replace megint resilver es igy tovabb.

Valaki tudná véleményezni, hogy BtrFS esetén ez hogy áll és vannak-e hasonló szívások? Gondolom vannak csak pepitában.

BTRFS FAQ írta:
btrfs combines all the devices into a storage pool first, and then duplicates the chunks as file data is created. RAID-1 is defined currently as "2 copies of all the data on different devices". This differs from MD-RAID and dmraid, in that those make exactly n copies for n devices. In a btrfs RAID-1 on three 1 TB devices we get 1.5 TB of usable data. Because each block is only copied to 2 devices, writing a given block only requires exactly 2 devices to be written to; reading can be made from only one.

https://btrfs.wiki.kernel.org/index.php/FAQ#btrfs

Leginkább a diszkek kicserélhetőségének és kötetek átméretezhetőségének flexibilitása érdekelne. Köszönöm.

Nem csak btrfs-sel lehet ilyet csinálni - igaz, mdraid/dmraid esetén az üzemeltető szürkeállományára is szükség van az adatok megfelelő elpakolásához.

Nekem eddig bevált a btrfs.
Még azt is túlélték az adatok, hogy az egyik SATA kábel meghibásodott és e miatt az egyik diszkre szemetet írt adat helyett.

Tény, hogy nem sikerült felállnia miután lecseréltem a diszket, de az is tény, hogy minden fájlt helyreállított a "btrfs restore".

Eldöntve.

Végül a Btrfs mellett született a döntés úgy, hogy a biztonsági mentés egyelőre Ext4 lesz. Ha hosszú távon stabilan megy Btrfs-el a dolog akkor a backup is át lesz téve Btrfs-re.
Volt pár érv a Btrfs ellen melyek ezek voltak:
- Win alatt nem lehet olvasni a Btrfs-t: Nem gond, van más linuxos gép ha esetleg bármi miatt át kellene tenni a diszkeket mentés vagy bármi célból.
- Copy-on-write, IO gond: Nem tárolunk rajta sem virtuális gép image-ket, sem adatbázist, tehát ez nem fog érinteni.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

A CoW fájlonként szabályozható, akár rekurzívan is. Ha lenne VM vagy DB, akkor sem gond, kikapcsolható azok fájljaira.

Ha a backup is btrfs lesz, akkor igen jó és takarékos backupot tudsz készíteni a btrfs snapshot, send, receive segítségével.
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup

Most jelenleg Ext4-en a backup 30 napra visszamenőleg minden napra megvan külön mappában. Azonos tartalmú fájok pedig hardlinkelve vannak. Ez meg van osztva Sambán és NFS-en csak olvashatóra. Itt nem csak a diszk elszállásra kellett gondolnom, hanem a kollégák bénázására is amikor rejtélyes módon tüntetik el a dokumentumokat, de csak 2 hét múlva veszik észre, hogy baj van.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Nekem van olyan szerver, ahol btrfs van és 5 percenként készül snapshot backup ilyen néven: 201708212020. Így 5 perces időgép van. Ráadásul alig fogyaszt lemezhelyet, sőt kevesebbet igényel mintha fájl szintű backup lenne.

Kukázott gépre mentés... Azaz mindegy, hogy a mentés jó, a mentés rendelkezésre áll, csak "legyen valami..."
A 4x4TiB az akárhonnan nézem, nettó 8TiB méretnél nem lesz több, ha nyugodtan szeretnél aludni - lehet persze azt mondani, hogy ha elszáll, akkor mentésből visszakalapálod, csak az a kérdés, hogy mennyi időre eshet ki a NAS,mert ennyi adatot visszalapátolni nem 1-2 óra.

Pár perc a várható kiesés. Ugyanis ha gáz van akkor a backup gép megkapja az éles gép IP-jét, az NFS és a Samba pedig újraindul egy másik config fájlal. Innentől minden gép élesként látja a backupot. Eközben meg vissza lehet tolni a mentést. A nap végén meg már csak a különbözetet kell újra rsyncelni.
Régebben már kellett ilyet csinálnom és elég jól működik ez az elképzelés.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Azaz egy aktív/passzív HA-t csinálsz úgy, hogy a passzív lába a kukázott gép, nem pedig backup-ot - így persze egészen más a leányzó fekvése.

Feltéve ha az online backup helytálló adattartalommal bír (pl. nem száguldott végig a megosztásokban egy cryptolocker..)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

AHogy írtam, ez nem backup, hanem aktív/passzív HA, kézi átbillentéssel... Ahogy a raid sem backup... De lehet belőle azt csinálni :-)

A backupot alapból csak olvashatóként lehet elérni.
A cryptolocker esélyét meg csökkentettem már évekkel ezelőtt azzal, hogy a szerkesztőségben a teljes gépparkon lévő rendszert WinXP-ről Debianra cseréltem.
Ezen kívül a backup gép riaszt ha a mentendőknél túl nagy az eltérés az előző naphoz képest.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Egy fokkal jobb, de ha a szerver megosztások mindenki számára írási joggal hozzáférhetők és bárki behordhat saját eszközt, amit aztán rádughat a hálózatra, akkor megint csak nullán vagy!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

ZFS: +1 Én FreeBSD-vel használom egy elég low-end vason (E8400 CPU, 2GB RAM, 2x160GB SATA). Kb. 10-12 gépet szolgál ki Samba-val. De akár lehetne FreeNAS is, vagy esetleg valami Linux disztróval, azzal viszont nincs tapasztalatom.

2 GiB ram nem sovány kicsit?
ZFS remek fájlrendszer, de a memória igénye az horror. Pláne a mostani mostani árak mellett.

Kb. 95%-on tele van mindig, de még nem volt gond neki. Van mellette 4GB swap is emlékeim szerint.

Erre van valami konkret ellentapasztalatod is, ami szerint sovany, vagy ami alatamasztja a horror memoriaarakat, vagy csak nem sikerult megertened a dokumentaciot?

Itt az a cél, hogy a körülményekhez képest egyszerű legyen mint a faék és minél régebbi vason is elfusson a dolog.

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Aminek régi, ócska sz@ron kell elfutnia/működnie, az nem fontos, úgyhogy raid 10, aztán hajrá :-P

A mentés van régi sz@ron, az éles adatok nem (mely raidben van) :-P

-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Raid10, spare diskkel és elég jó eséllyel nem lesz gondod!

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Négy darab diszkből kell dolgozni, ha egy spare, akkor másfél diszknyit tud összerakni tükörbe. Ha a hely és a megbízható tárolás (~nyugodt alvás) fontos, akkor inkább raid6, aminek megvan az az előnye (a retek lassú írás ellenében), hogy tetszőleges két diszk kipergését elviseli. És ez naaagyon jól tud jönni...

Ja, a disk darabszám-korlát elkerülte a figyelmem. Úgy tényleg ne csináljon raid10-et, a raid6 jó is backupnak, annak úgyse kell gyorsnak lennie.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ha egyszerű kell, mint a faék, én a FreeBSD-re szavazok. Ahogy említették előttem a 4 vinyó RAID10-ben (ZFS-ben nem egészen az, 2 mirror vdev). Kézzel sem egy agysebészet összerakni, de ha kattintós kell, akkor meg FreeNAS, jó admin felület, egyszerűen lehet kezelni a megosztásokat, legyen az Samba, FTP vagy NFS.

Van egy tippem, hogy az nem ECC RAM..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem ECC, de azt hiszem az alaplap támogatná.

hmm, btrfs 77, ext4 22...
érdekes. Én ext4-et használnék...

--
GPLv3-as hozzászólás.

Erről a "Mi mennyi?" vicc jut az eszembe.

Mik ezek a számok?

Napokban pont elpukkant a backup vinyómon a BTRFS partíció, leírnám én is a személyes tapasztalataimat. :)

Saját illetve szüleim gépén lévő Linuxok mind BTRFS subvolumeokra vannak rakva, amit frissítések előtt snapshotolok, a snapshotokat pedig külső backup vinyóra szinkronizálom btrfs senddel.

Kényelmi szempontból piszkosul jól működik ez a felállás, snapshotot lőni gyakorlatilag zéró idejű, backup vinyóra másolás is nagyon gyors így, sokkal gyorsabb, mint az rsynces régebbi megoldásom. Ha éppen hazaugrok pár hetente anyámékhoz, kb. 5 perc alatt megvan egy komplett mentés a teljes rendszerükről, tokkal-vonóval.

Ha gubanc van, visszaállítani a rendszert live linuxos pendriveról szintén roppant egyszerű, többször is volt rá szükségem (sajnos), tapasztalataim alapján ez is nagyon jól működik.

Így, hogy én azért nem 5-10 percenként snapshotolok, hanem mondjuk 1-2 hetente, írás/olvasás teljesítményben sem érzek visszaesést, HDD-re rakott rendszer esetén sem. A helytakarékosság is abszolút megállja a helyét, egy snapshot tényleg nem foglal extra helyet, egyedül azt kell megtanulni, hogy ha fogy a hely, hiába kezd el törölni az ember letöltött filmeket, amíg snapshot is mutat rá, addig az bizony foglalja a helyet továbbra is (laikusok, pl. szülők esetén ez probléma lehet).

De a sok ajnározás után a hátrányok:

Az, hogy jóval bonyolultabb a fájlrendszer, mint egy ext4, az sok extra hibalehetőséget is magában hord, sajnos még mindig bőven bele lehet futni bugokba.

A mostani esetem is ilyen volt, valószínűleg elfelejtettem leválasztani a külső vinyót lehúzás előtt. A partíciót nem lehetett többé mountolni, a recovery flaggel sem, egy kevésbé hozzáértő számára igencsak rejtélyes hibaüzenetek voltak a dmesgben. A btrfs rescue, meg a hasonló exotikus gyógyparancsok gyönyörűen elszálltak. Szerencsére a btrfs restore működött, azzal elég nehézkesen ugyan, de ki lehetett mazsolázni az adatokat.

Ha bajba kerül az ember, olyanba, ahol a recoverys mount se megy, akkor elég szívás tud már lenni a BTRFS. 200 fajta különböző fájlrendszer-javító, turkáló parancs van, egyik fele deprecated, másik fele kevéssé dokumentált, vagy éppen jó lenne a pontos megértéshez a BTRFS belső működésének az ismerete. Amit google kiad segítségeket, tutorialokat, stackexchange kérdéseket, szinte mind baromira elavult, vagy nem fog illeszkedni a te speciális hibádra.

Ha meg a BTRFS-es "beépített" toolok csődöt mondanak, akkor kb. búcsút mondhatsz az adataidnak mivel külső egyéb eszközt meg nem fogsz találni hozzá, a tömörítés, trükkös felépítés miatt a hagyományos (fájlminta-keresős) fájlrendszer kurkász toolok se fognak működni egyáltalán.

Sajnos egyik rendszeren ahol véletlenül dd-vel sikerült pár gigányit "belenyírni" a rendszer particióba, konkrétan belefutottam ilyenbe, ott kuka lett minden, még az se sikerült, hogy pár konfig fájlt esetleg megmentsek.

Szóval hobbi bohóckodásra, OS, kevésbé kritikus adat backupra hibátlan, értékesebb adatok esetén (üzleti alkalmazás, fontosabb családi fotók, videók, stb.) minimum tartanék még egy extra backupot más fájlrendszeren is.

Amit nem értek: ha szerinted annyira nagyon jó a Btrfs send/receive backupra, akkor miért más fájlrendszerre backupoljunk, miért ne Btrfs-re?
Nehezebb Btrfs backupból visszaállítani az adatokat, vagy nagyobb eséllyel romlik el az éles adat és a backup egyszerre, mint más fájlrendszernél?

>ha szerinted annyira nagyon jó a Btrfs send/receive backupra, akkor miért más fájlrendszerre backupoljunk, miért ne Btrfs-re?
Leírtam hová jó, hová kevésbé. Nem írtam, hogy BTRFS-re egyáltalán NE backupoljunk, hanem hogy tényleg fontos adatok legyenek más fájlrendszerre backupolva IS.

>Nehezebb Btrfs backupból visszaállítani az adatokat
Normál esetben nem, komolyabb gebasz esetén (fájlrendszer probléma) sajnos igen.

>nagyobb eséllyel romlik el az éles adat és a backup egyszerre, mint más fájlrendszernél?
Define "elromlik". HW hiba kevésbé fenyeget, mint más rendszernél, SW hiba sajnos inkább. Vagy bitre azt kapod, amit kiírtál rá, vagy fel se mountol, utóbbit sajnos nagyon könnyű elérni.

TL;DR: éles környezetben továbbra is orosz rulett, még mindig csak "kvázi stabil" fs. Kíváncsi vagyok, valaha fog-e ez változni.

Normál esetben nem, komolyabb gebasz esetén (fájlrendszer probléma) sajnos igen.
Komolyabb gebasz esetén nem csak annyi, hogy törlöm a hibás fájlrendszert és rárakom a mentést?

nagyobb eséllyel romlik el az éles adat és a backup egyszerre, mint más fájlrendszernél?
Define "elromlik". HW hiba kevésbé fenyeget, mint más rendszernél, SW hiba sajnos inkább.

Ha nem egyszerre romlik el a kettő, akkor a másikból az egyik könnyen visszaállítható.

Azt értem, hogy ha nincs mentésed és gebasz van, akkor nehezebben nyered vissza az adatokat, mint más fájlrendszernél. Ha van mentésed, akkor nem értem, hogy ennél miért lenne nehezebb visszaállítani, vagy miért jobb az, hogy más típusú fájlrendszeren van a mentés.

Nem írtam, hogy BTRFS-re egyáltalán NE backupoljunk, hanem hogy tényleg fontos adatok legyenek más fájlrendszerre backupolva IS.
Ezt értem, csak azt nem értem, hogy miért.

Most pl. ezzel szívok:

btrfs send -v "/mnt/root/home/@2017-09-07T22-28-40" | btrfs receive -v "/mnt/backup/os/laptop/home/"
At subvol /mnt/root/home/@2017-09-07T22-28-40
At subvol @2017-09-07T22-28-40
receiving subvol @2017-09-07T22-28-40 uuid=xxx, stransid=139490
ERROR: send ioctl failed with -2: No such file or directory
ERROR: unexpected EOF in stream

A fájlrendszernek egyik oldalon sincs semmi baja, scrub nem ad hibát, rsync átmásolja a céllemezre az adatokat ugyaninnen röhögve. Neten rákeresve találtam ismert, javított bugot ezzel a hibaüzenettel, de legfrissebb Arch Linuxon nem hiszem, hogy játszana.

Tegyük fel, hogy éles rendszeren vissza kéne húzni a backupot, minél hamarabb. A btrfs send meg ilyen csodálatos hibákat kezd neked dobálni, rosszabb esetben fel se mountol a lemez. Mivel esélyes, hogy magában a fában van valami trükkös dolog, amin eltaknyol a btrfs send, ezért a 2. BTRFS backup lemezről, ami lényegében az első másolata (ugyanazok a snapshotok lettek rá kipakolva), ugyanúgy nem fog kijönni az adatod.

Ha viszont van egy backupod ext4-en is, annak az esélye, hogy még azzal is van valami probléma, már mérhetetlenül kicsi.

Remélem így már érthető, mire gondoltam.

A backup nálunk pontosan ezért ext4 egyelőre.
-------------------
https://onlinestream.hu/ - A legtöbb magyar rádió és TV egy helyen!

Idézet:
Sajnos egyik rendszeren ahol véletlenül dd-vel sikerült pár gigányit "belenyírni" a rendszer particióba, konkrétan belefutottam ilyenbe, ott kuka lett minden

Ezt nem is csodálom.. :)

A dd-s túl magas labda, arra nem reagálok.

Nekem táp hiba, meg túlmelegedés stb. miatt rengetegszer fagyott resetre, spontán indult újra gépem/nason az elmúlt években, és soha nem történt ilyen hiba, pedig nem sima btrfs, hanem gpt->bcache->lvm->crypt->btrfs szóval elég sok helyen lehetne gond, mégsem szállt el adatom ilyen után egyszer sem!

Lehet, hogy régi kerneled volt? Elég sokat fejlődött stabilitásban a btrfs az elmúlt 1-2 évben, nekem Gentoon mindig új van, most 4.12.10, stb. nem lehet, hogy régi kernelt használtál, és olyan bug jött ki, ami már nincs meg?

Mondjuk hordozható winyón még nem használtam btrfst sosem, szóval ha ott valami nem olyan sorrendben íródott ki, mint ahogy a btrfs elvárná a journal miatt, akkor az lehet gond, de ezt nem tudom.

Idézet:
Mondjuk hordozható winyón még nem használtam btrfst sosem, szóval ha ott valami nem olyan sorrendben íródott ki, mint ahogy a btrfs elvárná a journal miatt, akkor az lehet gond, de ezt nem tudom.

A journal-nak szerintem pont ez a lényege, hogy mindegy hol szakad meg egy feladat, tudjon egy legutolsó jóra visszaállni anélkül, hogy az fs korrupttá válna. Tehát ezt az esetet kizárnám ha nem bug okoz ilyet.

>Lehet, hogy régi kerneled volt?
Nem, legfrissebb Arch Linux, alap (illetve egyik gépen zen) kernellel. Se RAID, se több lemezes kötet, se semmi extra, annyi csak, hogy bekapcsolt a tömörítés meg van pár VM nocowos mappában.

>szóval ha ott valami nem olyan sorrendben íródott ki, mint ahogy a btrfs elvárná a journal miatt
Erre gondoltam én is, de ha minden igaz ezt meg kéne oldania a 'recovery' opciós mountnak, vagy rosszabb esetben a 'btrfs rescue zero-log' parancsnak, de egyik sem használt.

Az amúgy, hogy a te környezetedben gyönyörűen megy, az nem sokat jelent, véletlenszerű hibákról beszélünk. Te a jobbik végére estél az eloszlásnak én meg rosszabbikra. Attól, hogy én így megszívtam vele, még nem lesz "szar", de azért elég jól jelzi, hogy ez bizony még mindig nem production ready.

A dd-re meg: mentségemre legyen szólva, hogy nem én csináltam, igazából elég kínos sztori volt, nem részletezném. :D
A lényeg az lett volna, hogy NTFS/EXT4 particióról ha mindent nyilván nem is, de valamennyi adatot meg lehetett volna még menteni, BTRFS-nél viszont kuka volt az egész. Ettől még persze annak a hibája a dolog, aki csinálta, meg az enyém, hogy lusta voltam backupolni előtte azt a gépet.

A journal is feltételezi, hogy a kiírás sorrendben történik, pl. a journal írásakor a journal ban szereplő írások már ki vannak szinkelve. Arra céloztam, hogy ha valamilyen usb hdd vagy ilyesmi miatt ez úgy van bufferelve, hogy ez az elvárás nem teljesül, akkor a journal is értelmetlen lesz. De ha ez igaz, akkor nincs olyan journal, ahol ez ne fordulhatna elő.

Amit írtam, hogy én nagyon régóta használom itthon, és sokáig szervereken is használtam, és nem volt vele ilyen gond, nagyon régi idők óta, amit te írsz :) Persze ha ilyen történt, és az fs hibájából, akkor valóban nem production ready. :)

Persze hogy a journal is korrupttá válhat, de mindig van egy legutolsó még jó verzió szerintem ha nincs hardveres hiba.

"performance for correctness"

Ez a lényeg. Beállítás kérdése valószínűleg a hibamentesség foka.

Nekem épp a minap szakadt össze a btrfs javíthatatlanul. Friss kernel, friss btrfs-tools stb... Már egy éjszakám ráment, de semmi haszna.

--
openSUSE 42.2 x86_64

Milyen oprendszer? Stabil (production ready) OS-t használtál? Milyen folyamat közben történt? Backup vagy OS van rajta?

SUSE 42.2

Youtube videó nézegetés közben a videókártya driver beokádott, emiatt pánikba esett a kernel, és viszlát subvol.

Jah, és ez az OS rootja. Szerencsére a home xfs.

--
openSUSE 42.2 x86_64

Hardveres gondot kizárod?

Az SSD gondját mostmár igen. Végig futott rajta a teszt, azt mondja semmi baja. A gépnek lehet hardveres baja, elvégre valamiért lefagy, egy olyan rendszer, amihez nem lett nyúlva.

--
openSUSE 42.2 x86_64

mem teszt sok órán vagy fél napon keresztül?

Megvolt, nincs baja.

--
openSUSE 42.2 x86_64

Attól még simán lehet hibás... :-)

Majd ha a kernelfordítás is megy rajta legalább 1 (de inkább 2-3) napig, akkor mondom rá, hogy nagy valószínűséggel hibátlan... ;-)

Jelzem, amikor xennel kísérleteztem asztali gépen, akkor a dma-k akadtak úgy össze, hogy random írt az fs memóriájába, ami kikerült a lemezre. Akkor nekem is széthalt a filerendszerem (nem mind szerencsére, de backup kellett). Ott egyértelműen ez volt a magyarázat (mert először nem tudtam mi történt, és megcsináltam mégegyszer :D ) Szóval ilyen ellen nem véd semmilyen fs szerintem, ha a zárt forrású vga driver olyan memória területre ír, ahova nem kéne, mindegy hogy hw, kernel, vagy driver hibából. Jó esetben kifagy a gép ettől, mielőtt lemezre íródna valami szemét.

Mivel egy komolyabb memory corruption jó eséllyel rövid úton kernel piknikhez fog vezetni, ezért a journal véd valamennyire. Illetve a COW loggingnak köszönhetően commit után is (jó eséllyel) megmarad az eredeti blokk is a lemezen, bár ha nincs rá snapshot, akkor nem tudom, hogyan lehetne értelmesen előbányászni.

Az az egy biztos, hogy nem illene a FS-nek úgy eltörnie ilyen hibáktól, hogy utána harapófogóval se lehessen már kiszedni belőle adatot...

Nézd, lemezre íródik DMA-val egy memória terület blokk eszköz szinten. És nem az, aminek kéne, mert nem az van (már) ott, aminek kéne. Erről nem tehet az fs, és hiába a journal, totál random kerülhet a lemezre... :) Ezért mondom, ha előbb fagy ki az egész gép, minthogy valami kiíródna, az a legjobb eset.

Egy gpu driver miatt ritkán pánikol el a kernel. Elég ram hiba gyanús eset. A gpu driver szokta magát először összeszarni akkor is, ha a rendszer ramnak van baja (ne kérdezd miért, de többször esett meg velem, hogy random kifagy a gpu driver, glitchel a kijelző és végül legtöbbször kiderült, hogy ram hiba, egyszer volt gpu rammal gond 8800-as geforceon..., simával meg 3-4-szer is láttam már ilyet)
A ram hiba magyarázhatja a fájlrendszer elhalását is.

Köszi! Ránézek megint. De ha egy éjszakai teszt nem volt elég, akkor mennyit menjen még a teszt?

--
openSUSE 42.2 x86_64

Hát...
Nekem ubi 14.04 alatt adott amd driver és adott chrome verzió(k) alatt rendszeresen produkált olyat egy gép, hogy egyszercsak szarráfagyott. Hálón is elérhetetlen volt, billentyűzettel is, csak a hard reset segített.
Ha --disable-gpu vagy valami hasonló paraméterrel indítottam a chrome-ot, akkor addig ment, amíg meg nem zabálta a memoárt és a swap-et, szóval nem memóriahiba volt. Aztán egyszercsak elmúlt ez a jelenség, nem tudom hogy chrome vagy driver vagy kernelverzió vagy micsoda okozta.

Az valami randa chrome bug volt, nekem intel GPU-val volt ugyan ez. Ott nem történt crash, elvileg az io terhelés nőtt meg borzasztóan nagyra, ezért lefagyott a rendszer. A chrome://flags-ben kellett valamit hekkelni.

Én ezt elhiszem, de egy userspace progi borította össze a gépet, és csak akkor, ha meg volt neki engedve a gpu használata.
Egy normális világban a chrome nem lenne képes a komplett OS-t összeborítani.

De sajnos igen, mert a hardveres gyorsítás miatt mélyre lenyúl, lásd amit régebben Hunger posztolt html fájl, amely minden OS-t megfagyaszt a webgl-t támadva. :)

Ha RAM hiba, akkor GPU-driver elhasalás nélkül is összerottyanna a fs időnként... Egy olyan fs, ami egy kernelpánik után képes széthullani, szerintem nem életbiztosítás éles adatok alá - és most igyekeztem finoman és visszafogottan véleményt mondani...

Mondjuk ez igaz. Ha nincs ram és disk hiba, akkor elvárt hogy ne hulljon szét. De ezt hogy látod be? Tudni kellene hogy ténylegesen mi történt.

Tényleg bejött a memória hiba. Mondjuk megkellett vele izzadni, mire kijött a hiba... Bár lehet túlzásba is vittem, mert miután a memtest felsorolta a teljes memóriát, szétfagyott...

--
openSUSE 42.2 x86_64

Az lehet amúgy táphiba is, ha csak terhelés alatt jön, ránéznék a feszültségekre (ha desktop). Illetve az is lehet, hogy csak kontaktos.

Laptop. Új (pár hónapos) az akku is, úgyhogy azt kizárnám. Bár attól még lehet a lapon szar valami.

--
openSUSE 42.2 x86_64

Nem hiszem, laptop esetén olyan 90%, hogy a ram rossz, 5% hogy a slot ment tönkre és a maradék 5, hogy a lap haldoklik.

Hétfőn megyek legariztatni a ramot. Most bentlévő ramokkal nem csinál galibát, de azért biztonság kedvéért újrakreáltam a komplett FS-t és átnéztem az SSD-t is badblocks-szal.
Ha ismét szar lesz, akkor az SSD is megy gariba.
Ha még mindig szar, akkor a gép is megy gariba.
Ha még ezután is, akkor leszokok a btrfs-ről.

--
openSUSE 42.2 x86_64

Ez nem oldja meg telepítés előtt a dupla metát? (-m raid1)

mkfs.btrfs -d raid0 -m raid1 /dev/sdX1

Sztem nem kéne. RAID az adat tükrözésért felel, nem pedig az adat konzisztenciáért - ergo ha hülye adatot kapsz a memóriából akkor azt a RAID szimplán kiírja a tömbben lévő minden diszkre (PV-re).
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Valóban, nem jót írtam. Ez a helyes:

mkfs.btrfs -d single -m dup /dev/sdX1

De megoldja, de nem ez a default. Ezzel csak azok foglalkoznak, akik mar beszivtak.

Rohadt sokáig ez volt a default :)

Sőt, most is az, ha igaz:

https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs
A single device filesystem will default to DUP, unless a SSD is detected. Then it will default to single. The detection is based on the value of /sys/block/DEV/queue/rotational, where DEV is the short name of the device.

Gondolom az alap feltételezés, hogy az ssd nem romlik el, vagy mittomen :D

unless SSD is detected

SSD igen.

--
openSUSE 42.2 x86_64

Igen, alapból olyankor nincs duplikálva, de be lehet kapcsolni formázáskor:
sudo mkfs.btrfs -m dup ...

Utólag is be lehet kapcsolni:
sudo btrfs balance start -v -mconvert=dup /toplevel/

Arról hol találok infót, hogy miért van ez így ?

--
openSUSE 42.2 x86_64

Mind a két linknél van információ róla:
The first way is mkfs.btrfs turns off metadata duplication on a single device when /sys/block/device/queue/rotational is zero for the single specified device.

This is equivalent to specifying -m singleon the command line. It can be overridden and duplicate metadata forced by providing the -m dup option. Duplication is not required due to SSD firmware potentially losing both copies. This wastes space and is a performance cost.

Illetve:
Explanation: on SSDs, mkfs.btrfs creates metadata in single mode (because of widely spread SSD deduplication algorithms negating duplicate entries). However, second copy of metadata increases recovery chances, especially so if your SSD does not deduplicate writes. Hence the desire to add metadata/systemdata duplication after the filesystem is created.

Köszi. A linket nem vettem észre.

--
openSUSE 42.2 x86_64

*potentially*

A levlistarol:

>From this point of view it doesn't make sense to store only one copy of
meta data on SSD... The bit flip probably happened in RAM when taking
the other garbage into account, so dup meta data could have helped here.

If the SSD firmware would collapse duplicate meta data into single
blobs, that's perfectly fine. If the dup meta data arrives with bits
flipped, it won't be deduplicated. So this is fine, too.

BTW: I cannot believe that SSD firmwares really do the quite expensive
job of deduplication other than maybe internal compression. Maybe there
are some drives out there but most won't deduplicate. It's just too
little gain for too much complexity. So I personally would always
switch on duplicate meta data even for SSD. It shouldn't add to wear
leveling too much if you do the usual SSD optimization anyways (like
noatime).

Ennek ellenere, hogy mar masok is tobbszor jeleztek ezt, meg mindig nem ez a default. Ezen felul check/repair tool meg segfaultol es nem torodnek vele. Kuldtem 1-2 patchet, meg az se, hogy szar vagy koszi. Kb ugyanolyan szarul megy a fejlesztese mint az ocfs2-nek ...

Erről valami link? Nem tudok ilyenről. Valami vallás tiltja, hogy ne legyen?


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

^^ Olvass fentebb. Roviden: deduplikaciora hivatkozva valaki szerint felelsleges ... Valos eletben viszont nem az!

Jó, de az előbb nem azt írtátok, hogy felesleges, hanem hogy nincs. Azt hittem, hogy valami technikai korlátja van, vagy a kernel nem engedi SSD-nél.


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek stb…” Aron1988@Proharder Fórum

? ... Ha SSD-t erzekel az mkfs tool, akkor nem duplikalt meta-val keszul el az FS. Azaz nincs backup tree, mert fs keszitoi szerint felesleges. Ahogy velem is massal is elofordulhat, hogy x honapig tokeletes minden, majd hirtelen megbolondul az egyik RAM.

Azt javasolnam mindenkinek, aki hasznalja ezt, hogy mindenkepp kapcsolja be a meta duplikalast ha SSD-t hasznal!

Megint ránéztem a témára mert a fileszervert kéne már frissíteni. Debianék továbbra is azt mondják hogy quota support nem az igazi s még volt 1-2 dolog ami bizonytalan.
A samba migrálásom nem sikerült úgyhogy elnapoltam a dolgot, de ha összejött volna akkor zfs on linux került volna a szerverre.

Legjobb tudomásom szerint production környezetben még mindig nem illik BTRFS-t használni. :(
Ha még is rákényszerülnél, forgasd alá a legújabbat backportból (most talán 4.9.0-0.bpo.3 ?) és eszedbe se jusson 3.X-et!

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."