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

Debian GNU/Linux

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.

( SzBlackY | 2017. 05. 25., cs – 20:42 )

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 :) ).

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.

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.

( dblaci | 2017. 05. 25., cs – 21:33 )

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!

( dblaci | 2017. 05. 25., cs – 21:40 )

"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)

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!

+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!

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.)

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

Valamennyire:

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)

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.

( Sanya v | 2017. 05. 26., p – 04:22 )

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.

( manfreed (nem ellenőrzött) | 2017. 05. 26., p – 07:24 )

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

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

( Ar0n v | 2017. 05. 26., p – 07:27 )

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.

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.

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.

( SySERR | 2017. 05. 26., p – 07:54 )

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!

( timi | 2017. 05. 26., p – 15:42 )

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.

( johans | 2017. 05. 26., p – 15:55 )

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

+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 :)

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.

( Lacyc3 v | 2017. 05. 26., p – 16:14 )

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.

( kisg v | 2017. 05. 27., szo – 22:43 )

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

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.

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#p2…

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.

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?

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

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.

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.

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

( gthomas | 2017. 05. 30., k – 07:15 )

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".

( SySERR | 2017. 08. 21., h – 12:16 )

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!

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!

( zeller | 2017. 08. 30., sze – 16:16 )

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!

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!

( kleinie | 2017. 08. 31., cs – 12:37 )

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.

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

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.

( b | 2017. 09. 02., szo – 00:12 )

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

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

( juliusk | 2017. 09. 04., h – 11:33 )

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

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. :)

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.

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.

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

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!"..

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

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.

*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

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!

( elod v | 2017. 09. 04., h – 11:53 )

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.

( andras0602 | 2017. 09. 04., h – 14:00 )

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."