Dotaz: Btrfs využití na USB disku

[Ivan39]

Zdravím, chtěl bych se zeptat jestli lze nějak vyzkoušet možnosti BTRFS na externím plotnovém usb disku, když prozatím mám systém na ssd formátovaném na ext4? Jedná se mi o vyzkoušení subvolume a snapshotů. Nebo musím mít / naformátovaný bezpodmínečně také na BTRFS? Zatím mám takhle naformátovaný 1TB wd disk s ne moc důležitými daty.

---

---

Odpovědi

[Jendа]

Samozřejmě, je to blokové zařízení jako každé jiné a subvolumes a snapshoty takhle běžně používám - typicky mám takhle nějaký disk připojená do /mnt/backup a tam vždycky rsyncnu zálohu a udělám snapshot.

[OldFrog {Ondra Nemecek}]

…a tam vždycky rsyncnu zálohu…

Chyba; rsync není atomická záloha a navíc ještě vyhazuje oknem ven všechny výhody snapshotů a s nimi související deduplikace. rsync pro zálohy dává (částečně) smysl jedině s read-only zdrojem — a jen při velmi liberální definici pojmu „dávat smysl“.

…a udělám snapshot.

Nesprávné pořadí kroků vede k porušení atomicity a k plýtvání prostorem. Správný postup je

1. udělat atomický read-only snapshot na zdroji záloh,
2. pomocí btrfs send ... vytvořit „rozdílový stream“ proti minulému zálohovacímu snapshotu,
3. v cíli záloh nechat pomocí btrfs receive ... vytvořit další snapshot odkazující se na předchozí cílový snapshot.

Takový postup (0) zachovává vždy všechny atributy souborů a adresářů, současné i budoucí, i takové, které rsync nezná, (1) zachovává atomicitu zdroje i cíle, (2) neduplikuje už zálohované a nezměněné bloky a (3) přenáší / kopíruje jen to, co je třeba.

Skvělé taky je, že pro úsporu místa na zdroji stačí udržovat jen jeden (předchozí) snapshot, aby inkrementální zálohování fungovalo. Cíl (u kterého se předpokládá větší kapacita) může držet víc snapshotů, chce-li, a ty historické třeba postupně „ředit v čase“ na základě nějakých kritérií (například: (0) chci mít snapshot starý aspoň takhle, (1) chci mít nanejvýš tolik snapshotů a (2) chci, aby rozdělení stáří snapshotů bylo „exponenciální“ nebo podobné; nejnovější budou nejhustší, starší budou řídnout — tohle už se dá snadno naskriptovat).

Cokoliv jiného je asi jako petrolejka v éře LED.

[volal Pelta s.r.o]

Nebyl bys ochotný třeba v blogu popsat víc do detailu kroky 1-3?

[k3dAR]

"presne", sice si o tom muzu neco najit a pak treba znovu premyslet o BTRFS, ale pokud by Andrej se o tom rozepsal do blogu, tak si to rad cesky prectu od nejako v tom "fascinovaneho" a muze to mit 1000x vetsi vahu nez jeho neustale narazky/urazky EXT4 ktere me od BTRFS spis vzdy odrazuji

[Andrej]

Co bych měl popsat? Udělat Copy&Paste něčeho z man btrfs-send a man btrfs-receive? To podle mě nemá smysl dávat do blogu. (Kromě toho nejde o nic nového; tenhle princip má svou dlouhou historii už od dob ZFS, tj. minimálně desetiletí a půl zpátky.)

[LarryL]

Možná by stačilo kdybys hodil odkaz na nějaký script, který ti připadá dobrý pro automatizování zálohování pomocí btrfs send/receive.

[čavo]

Myslím, že btrbk využíva send-receive na btrfs. ( https://digint.ch/btrbk/ ) Hádam, že bude aj vo vašej distribúcii. V Gentoo je. Niekto tu už, na článok na root-e, odkaz dal.

[LarryL]

To už je hodně komplexní script, představoval jsem si něco jednoduššího, ale dík dám si to do své wiki.

[Fredy72]

tady návod, starší, ale asi se nic nezměnilo odkaz

[volal Pelta s.r.o]

Děkujem,

Článek je psán v dobré víře, bohužel dosti vět je více-méně zmatečných, zasloužilo by si to doupravit.

Je mnoho lidí, kteří ještě nezálohují a tak doufám, že tento návod to pomůže změnit.

Tak kdyby existoval ještě nějaký XUI program se všemi možnostmi. Naposledy jsem "snapshotoval" v ranných verzích yast2-snapper, to umělo jen vytvářet snímky a to ještě tak že tak že si činnost uzurpovala téměř 3/4 výkonu PC.

[Petr Tomášek]

navíc ještě vyhazuje oknem ven všechny výhody snapshotů a s nimi související deduplikace

Hovadina. Rsync a snapshoty se dají výborně kombinovat. Jsi nikdy neslyšel of rsync -c --inplace --no-whole-files ?

[OldFrog {Ondra Nemecek}]

A má ta kombinace nějaké benefity?

[Andrej]

rsync a snapshoty se dají kombinovat podobně jako mléko s citrónovou šťávou. Jasně, dají se kombinovat, ale ta kombinace je na řídké hovno.

Dál bych podotkl, že --inplace --no-whole-file v tomto kontextu není velká výhra: Nepomáhá s efektivitou v tom smyslu, aby se od minula nezměněné bloky vůbec nemusely číst (natož přenášet a zapisovat).

Stating the obvious, --inplace má asi tak všechny myslitelné nešvary, jaké si u špatného zálohování lze představit — problémy s atomicitou všude kolem, spousty okrajových případů s nekonzistentním výsledkem atd. Manuálová stránka nabízí u --inplace obsáhlé počtení k těmto chmurným tématům.

Zálohování pomocí atomických snapshotů nad CoW filesystémem a k nim příslušných send / receive příkazů žádnou takovou↑ spleť problémů nemá.

[Andrej]

…jestli lze nějak vyzkoušet možnosti BTRFS na externím plotnovém usb disku…

Nebo musím mít / naformátovaný bezpodmínečně také na BTRFS?

Inu, záleží na tom, co přesně chceš vyzkoušet. (Mimochodem, víc než dekádou prověřený a velkými distribucemi doporučený souborový systém Btrfs není třeba nějak zkoušet; stačí ho zkrátka normálně používat. Just sayin’.)

Samozřejmě lze vyzkoušet Btrfs na kterémkoliv jednotlivém blokovém zařízení. Třeba na loopback souboru nad Ext4 fosilií. Nebo na loopback souboru nad ramdiskem (tmpfs); proč ne, moc trvanlivé to sice nebude, ale na bleskově rychlé experimenty se to skvěle hodí. Nebo na plotnovém USB disku. Nebo na Thunderbolt SSD. Nebo na SD kartě, na USB flashdisku atd. atp… Všude se hodí Btrfs.

Jenže: Pokud chceš naplno využít všechny výhody Btrfs, a zejména jednu z jeho killer features — atomické inkrementální zálohování pomocí zdrojových a cílových snapshotů a btrfs send / receive —, v takovém případě je potřeba mít Btrfs na „zdroji“ i na „cíli“ záloh. Jinak bude případné zálohování vypadat (jak už jsem psal v jiném komentáři) jako petrolejka v éře LED.

[Petr Tomášek]

Jo, a největší killer feature BTRFS je, že když se ti rozpadne filesystem, tak už ho nespravíš. Ext4? Normálně fsck a s trouchou štěstí ti to opraví, přijdeš o pár souborů (ideálně nahradíš ze zálohy). Btrfs? Jakmile se tito posere, tak totálně.

[Andrej]

Prdlajs. Jak přesně opraví ten zázračný Ext4 fsck posraná data, u kterých nemá checksum ani redundanci??? Btrfs je buď obnoví z kopií, nebo zkrátka upřímně řekne, že jsou pryč. Ext4 ti bude servírovat náhodné kraviny.

Btrfs je nesrovnatelně spolehlivější, protože zaprvé poskytuje vestavěnou redundanci, chce-li ji uživatel (na jednom zařízení i přes několik zařízení), a zadruhé má checksumy dat, ne pouze metadat.

Když se posere hardware, na kterém je Btrfs — v drtivé většině případů tedy ne Btrfs jako takový —, dozvíš se o tom, což je klíčové.

Ext4 máš posraný už teď, bit sem, bit tam, nám už je to všechno jedno — jen o tom nevíš a dozvíš se to, až jednou ty poškozené soubory budeš potřebovat. Jenže poničená data už budou zkopírovaná i do všech záloh — pozdě brka honit.

Sorry jako, ale tohle téma se tu už řešilo tolikrát, že i hodně hloupí FUDisté si už musí připadat hloupě. Nevím, jak to říct diplomaticky.

Recovery nástroje pro získání „aspoň něčeho“ z disku sejmutého kladivem pro Btrfs samozřejmě jsou — jen si nebudou hrát na to, že z příslušného guláše vykouzlí konzistentní filesystém. V takové situaci to vůbec nedává smysl.

[Petr Tomášek]

LOL, pěkný sračky nám tady bulíkuješ.

fsck ti u ext4 vždy uvede do použitelného stavu (ať už ztratíš soubory nebo ne), nalezené soubory nebo segmenty dá do /lost+found. Když se ti skutečně rozpadne btrfs, tak z něj nemáš šanci získat funkční filesystém. V lepším případě to nenamountuješ, v horším to namountuješ s tím, že se ti postupně ten filesystem bude rozpadat a budou se ti poškozovat staré soubory, do kterých se ani nezapisuje. Zažil jsem několikrát. To, že má prostě btrfs debilní strukturu a nedodělané fsck ani ty checksumy nezachrání...

[k3dAR]

Sorry jako, ale tohle téma se tu už řešilo tolikrát, že i hodně hloupí FUDisté si už musí připadat hloupě. Nevím, jak to říct diplomaticky.

a ze si nepripadas hloupe ty, v minimalne tom jednom reseni sem psal sve zkusenosti s BTRFS kdy 2 z 2 pokusu o jeho nasazeni skoncily do tydne zkolabovanim BTRFS a nepomohlo zadny z jeho opravnych nastroju... a take to ze s EXT4 naopak sem na zadnej problem za 10let a nasazeni na XY disku ci mdadm poli nenarazil... toz ti preju dalsi tve arogantni a napul lzive komentare kterejma budes v tom kolobehu pokracovat

[Andrej]

Ten bájný pokus o nasazení Btrfs se odehrál na zcela novém a bezproblémovém hardwaru, kvalitou srovnatelném s tím, na jakém běžely (údajně) bez problémů jmenované fosilie? (Údajných 10 let bez problémů nelze bez atomických checksumů dat nijak doložit, tudíž jde všeho všudy o zbožné přání.)

Nebo je to opět ta ohraná písnička na téma "zkoušení" Btrfs na starém vyřazeném hardwaru a divení se, že ten hardware není v pořádku a že si toho Btrfs všimne?

K těm údajným kolapsům Btrfs bych si moc rád přečetl příslušné bug reporty. Jistě jsou zajímavé a poučné. Odkazy by byly?

[k3dAR]

odehral se na totoznem HW na kterem predtim i potom ext4 chodi/lo ok, tedy slo o stx s i3-7100t + 16GB RAM, system na NVMe WDBlack, data na 3TB 2.5" NonSMR Toshiba - na 1 disku bylo ext4, na druhem novem disku sem dal BTRFS, zkopiroval na nej data, po restartu byl mountpoint prazdnej a mount nehlasil ani zadnej error (do stdout ani logu), dohledal sem si tehdy vhodne poradi pouziti oprav btfs, zabrala az ta posledni, ale filesystemu sem neveril, nechal ho nejakou doby byt a pak po tom co nekolikrat cetl sr&cky od jednoho Andreje, sem se na BTRFS vykaslal, druhy disk pridal do mdadm s tim prvnim, a od te doby par mesicu ok, cast dat co ma md5 sem projizdel a bylo OK...

na nekterejch serverech s ext4/lvm/mdadm mam ruzne iso jejichz md5 soucet sedi, dalsi data ktere nemaji md5 nemeli za tu doby problem precteni = zobrazilo se to co melo...

ono lhat, mit trapne kecy a zpochybnovat zkusenosti nekoho jineho klidne muzes, stejne tak ty nebo dalsi muzou mit 50let pozitivni zkusenosti s BTRFS, pokud ale me 2 pokusy s BTRFS skocili (prvni) po tydnu naborenym FS, (druhy) po par hodinach (prazdne mountpointy) a na tom samem HW pretim a potom disky s EXT4 data drzej, tak to ma pro me vetsi vahu nez arogantni kecy

A to sis to nevyzkoušel na něčem menším? A neošahal jsi si to? raid1, dup, single, změna jednoho na druhé, přidat disk, ubrat disk, scrub, check... S tvým skóre na abclinuxu??? Ono je to přece jenom něco trochu jiného ...

[k3dAR]

a co je podle tebe mensi nez 1x novy disk jako single naformatovat na BTRFS a nahrat tam data z jineho disku? k raid1, dup ani snapshot sem se ani nedostal, jen format, vytvoreni subvolume, rsync dat a po rebootu nikde

[Jendа]

Jako na btrfs se dějou za provozu různé corruptions (na ostatních FS taky, ale fsck to typicky opraví), ale takhle jednoduché věci jako fakt fungujou, tohle bude chyba na tvé straně.

[k3dAR]

to nepopiram, ale v nejakem tom minulem vlakne sem se snazil popsat vsechny kroky co jsem delal (v podstate jedinej potencialne zavadnej mohlo byt prejmenovani "adresare" s subbolumes) a z nikoho chyba me strany nevypadla, tedy mel sem opravdu snahu se dopatrat proc se ten problem stal, ale tim ze se nic nezjistilo tak proste dalsi pokus o nasazeni BTRFS zas odlozen

[LarryL]

Vzpomínám si, že jsi to řešil tady a pokračování tady. Taky mne tenkrát zajímalo, proč se ti btrfs rozsypalo.

[k3dAR]

jj, diky za pripomenuti, vypadlo mi ze ten prvni pokus byl vlastne prevod z ext4, coz jak sem pak cetl vsude i tady, je silne nedoporucovane (nebo alespon v te dobe) reseni, druhej pokus uz byl cistej format (na jinem, tom zde psanem HW)

Například si vytvoříš virtuální mašinu, přiřadíš jí jeden, dva, tři, ... virtuální disky, naformátuješ je na btrfs a zkoušíš.

[k3dAR]

proc bych priradil virtualu >1 vdisku kdyz sem chtel zkusit format 1 a nakopirovat tam ~2TB realnejch dat rozdelene do nekolika subvolumes na 1 oddilu?

[Aleš Kapica]

No jo. Odvážná školačka. To se hned pozná.

[Vackar]

Tak na plotnovém disku je to ok, ale před používáním BTRFS na SSD varuji a již bych tento fs nepoužil. Tímto fs mi ssd Samsung 500GB klekl po roce a čtvrt. Reklamace nebyla možná kvůli překročení TBW. Mám tady ještě dva disky Samsung 250GB ext4 na kterých je stejné distro a provozoval jsem na nich naprosto stejnou činnost spoustu let a TBW okolo poloviny životnosti. Pokud bude brát ssd jako spotřební zboží podle některých jedinců a po roce je házet do popelnice tak skvělých vlastností BTRFS užívejte

[tamtung]

Ty SSD, co to bylo za modely?

[Vackar]

Samsung EVO

To jsi na ty disky musel docela fest zapisoval. Každý den jsi je musel tak jedenapůlkrát celé přepsat. Co jsi s nimi prováděl?

[Vackar]

Však to píšu v prvním příspěvku. Malé disky jsou ok protože jsem je používal s ext4 a ten 500GB s BTRFS kleknul po roce s překročeným TBW. Jsem vyléčen a nikdy více to zkoušet nebudu

Zapsat každý den na disk nějakých 600-750 GB dat, to dá při běžném používání dost práce. Proto se ptám, co jsi s nimi prováděl?

[Peter Golis]

Stačí urobiť raid mirror medzi /dev/mem a /dev/nvme0n1

[Petr Tomášek]

Tak btrfs má jednu (doslova) killer feature a tou je fragmentace. Malé databáze (např. sql, co používá firefox pro ukládání těch svých blbinek) jsou na to ideální.

[Andrej]

Ta killer feature se nejmenuje fragmentace, nýbrž mount -o autodefrag.

Další FUDista se spletl.

[Petr Tomášek]

Jasně, pro životnost SSD je to to úplně nejlepší, aby ti tam furt šmejdil nějaký démon a defragmentoval. LOL.

(Jo, a taky si toho většina všimne, až když jim to SSD odejde...)

Ale on s tebou Andrej zřejmě souhlasil v tom smyslu, že -o autodefrag ty disky opravdu může pomoci oddělat.

[Petr Tomášek]

No a bez ní je odděláš tuplem .

Takže si nevybereš, o to jde.

Maximálně, co můžeš zkusit, je nastavit NOCOW, ale pak už je skoro lepší jakýkoliv NOCOW-filesystem... jako např. ext4...

Řekl bych, že zatížená mysql databáze nad btrfs není úplně dobrý nápad. A zatížená mysql databáze nad btrfs s volbou autodefrag je ještě horší nápad.

https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/

[[Jooky]]

To je cisty nezmysel co pises. 500 GB EVO disk ma 300TBW. Ak si za 1.25 roka "pretocil" TBW, tak to znamena, ze si denne musel zapisat ~673 GB ... na 500 GB disk. Prepisat disk 1.4x denne urcite nie je skrz vyber filesystemu, ale skrz to ako sa system pouzival ...

Pre porovnanie. Ja mam v laptope "Samsung SSD 860 EVO 2TB". Do laptopu som ho daval 10.10.2019 (k dnesnemu dnu ma 1048 dni, uz skoro 3 roky). "Power_On_Hours" ma 7991 ... na disku mam Luks+btrfs a bezim nad tym Linux, ktory denne pouzivam. Mam tu aj windows10 vo VB. Laptop pouzivam na kadeco aj vratane napr. pracu s videom (mam tu teraz priecinok s 58 tisic fotkami, z ktoreho idem renderovat video) ... Aktualne mam Total Bytes Written (TB) -> 101.13 TB

[Vackar]

Já ti to věřím podobnou zkušenost mám s 250GB diskem! Ten 500GB jsem měl s ext4 cca 3týdny. Potom jsem nasadil BRTFS, ale TBW mě nenapadlo sledovat. Na disku jsem mimo velikých databází nic podstatného neměl a nepoužíval. Ty db jely 24/7 ale nevím proč mi tento fs TBW požral . Koupil jsem si tedy 1TB ssd opět Samsung, fs mám ext4 a TBW naprosto v pohodě.

[Aleš Kapica]

Na disku jsem mimo velikých databází nic podstatného neměl a nepoužíval.

Co kdyby ses tak trochu rozepsal o jaký typ databáze šlo? Brfs nad SSD totiž není pro některé zrovna optimální FS. A pokud jde o ext4. TWB můžeš mít v pohodě a zároveň data v háji aniž bys měl tušení. A jsou databáze, co mají mechanismy, které brání aby k tomu došlo, jenže u COW souborových systémů, co běží na SSD, kde mají buňky limitovaný počet zápisů ti to může utavit disk, pokud je na to sám.

[Petr Tomášek]

nepouzivam DB ani BTRFS, ale i tam sem cetl vsude ze pro DB je CoW peklo SSD zapisove, z principu jak to funguje a jak ssd prepisuje velke cele bloky pri kazdem zapisu bajtu, nedavno nekdo na root.cz resil neco podobneho ale s ZFS, tak mu SSD s DB odeslo to 1-1.5roku, tam dospeli k nejakym navrhum upravy nastaveni DB aby ten problem radove snizil... jo tady to je

[Vackar]

Moc děkuji za odkaz. Nj ZFS je taky CoW fs. Doufám že to nebude znít škodolibě, ale jsem rád že to nepostihlo jenom a pouze mě z nějakého pebkáče Jak jsem psal výše na novém disku již pokusničit a riskovat nebudu. S TBW na ext4 jsem naprosto spokojený bez jakéhokoli nastavování. Měl jsem se držet starého dobrého "co funguje neměnit a nevrtat se v tom". Stálo mě to ssd disk a mohu si za to sám.

[Andrej]

"co funguje neměnit a nevrtat se v tom"

Jenže Ext4 nefunguje. Odtamtud dál ja pak už celá úvaha špatně.

[Kit]

Znáš nějaký lepší souborový systém pro provoz databáze na SSD? Nejlepší by asi byl RAW, ale není úplně praktický. Líbil by se mi LVM, ale netuším, zda je to možné.

[Andrej]

Znáš nějaký lepší souborový systém pro provoz databáze na SSD?

Znám.

[Kit]

Hmm, takže neznáš a jen kalíš vodu.

[Petr Tomášek]

Ext4 funguje 100x spolehlivěji než btrfs...

[Andrej]

Ext4 funguje 100x spolehlivěji než btrfs...

Solidní statistiky k tomuto↑ debilnímu žvástu najdu kde přesně???

Ext4 je předpotopní nespolehlivý FS z dob 10GB disků, kdy se disky považovaly za spolehlivé a tak celkově se spoléhalo na zázraky. Btrfs je nesrovnatelně spolehlivější, zhruba ve smyslu 1 – pravděpodobnost chyby disku krát pravděpodobnost kolize checksumu.

Smiřte se s tím, zoufalí zapšklí FUDisté. Takhle to prostě je. Takhle ten dnešní svět funguje, víme???

[Jendа]

Btrfs je nesrovnatelně spolehlivější, zhruba ve smyslu 1 – pravděpodobnost chyby disku krát pravděpodobnost kolize checksumu.

Ano, protože chyby v datech co vrátí disk jsou jediné chyby které se v počítačích objevují.

[Petr Tomášek]

To není pravda. Nedávno mi segfaultnul jaderný modul btrfs a stihl ještě rozesrat celý filesystém...

[Jendа]

modprobe irony

(nežereš ovoce, nepoznáš vtip :D)

[Petr Tomášek]

No, u tebe člověk nikdy neví

[Petr Tomášek]

Nějaké "statistiky" mně jsou celkem u prdele. Vím, kolikrát se mi osobně rozesral btrfs (několikrát neopravitelně) a kolikrát ext4 (nikdy neopravitelně).

Největší prdel byla, když v btrfs došlo k chybě, která se projevila po několika letech, když se vývojáři rozhodli přidat nějaký check, nažeč zničeho nic po upgradu kernelu prostě nešlo btrfs přimountovat, i když do té doby to léta fungovalo.

Btrfs je teoreticky lepší, ale v praxi je to bída...

[Andrej]

Reakce na tenhle FUD, která se kvůli (už cca rok otravujícímu) bugu v ABCLinuxu nedá vložit do vlákna, kam patří…:

Obrovský objem zápisů, způsobený nejspíš tím, že si uživatel něco špatně nakonfiguroval a to něco pak psalo a psalo — můžeme hádat, který validator node to asi byl , se tady nesmyslně svádí na souborový systém.

Mimochodem, proč je jisté, že to „způsobil“ Btrfs a nikoliv třeba (omylem použitý) swap na SSD? Nebo to není až tak jisté…?

Tohle je asi jako: „Měl jsem Rolls-Royce, ale řídil jsem ho ožralý a naboural jsem se do stromu. Tak už jsem vyléčený z takových nápadů — Rolls-Royce už nikdy více. Budu řídit Trabant! S Trabantem se mi rozhodně nemůže stát totéž!“

Otázka je, jaká je asi motivace těchto anonymních FUDistů. Cui prodest?

[Petr Tomášek]

V prípade DB by som nepoužil výraz SWAP, ale LOG AREA. Aj keď tých žurnálovacích úrovní majú rôzne DB viacej.

A vynechal by som expresionizmy. Na niečo je vhodný EXT4, na niečo iné BTRFS alebo ZFS, či nebodaj SquashFS alebo GlustreFS. A používať SWAP v dnešnej dobe lacných a veľkých RAM je mimo hibernácie už nemoderné.

[Want]

Na niečo je vhodný EXT4, na niečo iné BTRFS alebo ZFS, či nebodaj SquashFS alebo GlustreFS.

Mícháš jabka s hruškama.

Swap má svoje opodstatnění, když víš co a proč děláš. Pro mne je to bezpečnostní pojistka. Swapuje se jen když paměť nestačí, takže když swapování začne a mám něco rozdělané, mohu ještě něco řešit. Bez swapu bych byl namydlený, protože 128GB RAM v notesu nemám.

[Peter Golis]

Mícháš jabka s hruškama.

Hrušky by som kedával zapiecť ku kačici, jablká áno.

Swap má svoje opodstatnění, když víš co a proč děláš.

Swap som v posledných rokoch používal len na hibernáciu. Ak už systém zletí do swapu, tak je počítač na môj vkus pomalý.

Bez swapu bych byl namydlený, protože 128GB RAM v notesu nemám.

Nechávať si v notebooku 128GB RAM na swap je aj na môj vkus trošku veľa.

Ale asi som divný.

[Vackar]

Nesnížím se k používání expresivních výrazů. To že jste fanatický příznivec BTRFS fs vám nikdo nebere i když je mi záhadou co je právě vaší motivací. Vše co jsem uvedl v prvním příspěvku je moje zkušenost nic více nic méně. Možná to tazatele přiměje k tomu aby si nevýhody tohoto fs ověřil. Nevím proč bych měl na novém disku něco s BTRFS ověřovat a čekat kdy klekne. Jak jsem psal, změnil jsem pouze fs a nic jiného. Navíc podle vás s nefunkčním ext4 je o poznání svižnější. Tímto končím a přeji vám hodně radosti s BTRFS. Na můj disk již nesmí.

Vše co jsem uvedl v prvním příspěvku je moje zkušenost nic více nic méně. Možná to tazatele přiměje k tomu aby si nevýhody tohoto fs ověřil.

Vytáhnout z vás informaci, co jste provozoval na tom jednom disku, kde jste měl btrfs a který vám odešel, dalo spoustu práce a ještě si nemůžeme být jisti, že jste napsal všechno, natož pak podrobně. Lezo to z vás, jak z chlupaté deky. Takže je těžké brát vaši zkušenost za bernou minci pro rozhodování, jestli btrfs ano nebo ne.

[Andrej]

Dokonalé. Naprosto přesně jak jsem psal:

„Řídil jsem ožralý Rolls-Royce a nabořil jsem se s ním do stromu. Proto odteď řídím Trabant. Rolls-Royce už do mých rukou nesmí!“

Inu, hodně štěstí s postupně mizejícími daty na předpotopních FS typu Ext4. Dvě věci jsou nekonečné, že ano…

[Petr Tomášek]

Inu, hodně štěstí s postupně mizejícími daty na předpotopních FS typu Ext4.

Tím už tady vyhrožujete léta, ale zatím tu víc lidem zmizela data na tom moderním a skvělém BTRFS...

[Andrej]

Kdybys tak Bourku nekecal.. To by bylo prima.

[Andrej]

Komu? Kde? Kdy? Na jakém přesně hardwaru? (Novém?) V jakém experimentu / srovnání? Který jiný FS (by) ustál totožnou situaci?

Fakta? Čísla? Kde jsou?

Hele, FUD je zkrátka na hovno. FUD má holou prdel.

Ještě tak v roce 2012 by tohle bylo snad i vtipné (s jízlivým úsměvem typu „no tak to nepoužívej, když nechceš; ona to použije schopnější konkurence“). Nicméně roce 2022 … nevím, no. Asi někdo příliš dlouho hibernoval.

[trekker.dk]

V reakcích lidí na vaše komentáře. Že je usilovně ignorujete, s tím nikdo nic nenadělá.

[Andrej]

Takže fakta a čísla nejsou.

Děkuji za potvrzení. Klasika. Jako vždy.

Už se těším na další perly typu "vytáhl jsem ze sklepa 15 let starý notebook, dal jsem na něj 'na vyzkoušení' Btrfs a světe div se, on se mi tam objevil checksum error". Pořád ta samá hloupá písnička.

[trekker.dk]

Děkuji za potvrzení. Klasika. Jako vždy.

Nemáte zač, tu klasiku jako vždy, kde ignorujete realitu a nahrazujete ji svou vlastní, jste tady napsal sám.

[lertimir]

No jenže právě to slovo "léta" je důležité. Protože před léty btrfs mělo některé vlastnosti, které při neopatrném používání měly neočekávané důsledky. A i souhlasím s tím, že některé vlastnosti byly vývojáři zpochybňovány a bagatelizovány. Např vzpomínám na to, jak hloupě btrfs hlásilo volný prostor do df.

Ale tohle všechno je dávno pryč. Používám už více než 10 let btrfs všude. Na nvme, SSD i rotačních discích. Důležitá data v RAID 1 a mnoho nedůležitých dat na singl discích. Celkem tak přes 40TB na cca 10 rotačních discích. Vzhledem k tomu, že pravidelně měsičně btrfs provádí scrub testy, tak vím, jak data na těch discích jsou. A mohu ti potvrdit, že chyby check sumu se objevují. Pokud se začnou objevovat více, tak disk se posune u mne do pozice nedůvěryhodného a jsou na něm jen data, které mi nevadí, že o ně přijdu. Znamenají jen nějaké opětovné stažení z netu. A celkem za ty léta jsem na základě btrfs scrubu vyřadil již 4 disky. A teď už mi asi odchází 8TB WD green, který ve scrubu má každy měsíc jednotky chyb. (a samozřejmě zjistíš v jakých souborech ty chyby jsou a když je to btrfs RAID1 tak je chyba opravena) Jinde tu kontrolu nemáš. Max můžeš disk přečíst a to zjistíš jen read error a ne špatný checksum. Takže to, že z např. ext4 nikdo nereportuje ztrátu dat může být jen to, že na ni nepřišel.

[Jendа]

Vzhledem k tomu, že pravidelně měsičně btrfs provádí scrub testy, tak vím, jak data na těch discích jsou.

Fun fact: scrub nekontroluje strukturu filesystému ("fsck"), chyby na tebe vypadnou klidně až když se nějaký soubor pokusíš opravdu přečíst.

Každopádně je super že jsi na tohle narazil -- zkoušel jsi zkoumat jak to vypadá? Je v tom sektoru pár bitflipů, mění se to když to přečteš po power cycle, jsou tam samé nuly…?

[lertimir]

Souhlas. Scrub (tak jak mám informace) kontroluje pouze jestli data z disku jsou v pořádku, tedy jak byly zapsány a odpovídá jim kontrolní součet.

Příklad. Teď k 1.9. se o půlnoci spustil pravidelný scrub a toto je dnešní první chybová hláška

[265079.706162] BTRFS warning (device dm-7): checksum error at logical 26544592297984 on dev /dev/mapper/miraza, physical 230671491072, root 5, inode 5670856, offset 189988864, length 4096, links 1 (path: hudba/pracovni/Beethoven_Piano Concertos - Maurizio Pollini, Claudio Abbado & BPO [2021 Esoteric]/No.1 & 2/04 - 1. Allegro con brio [Piano Concerto No.2 in B flat major, O.dsf)

Je to na RAID1 takže bez problémů byla korekce. /dev/mapper/miraza je LUKS šifrovaný disk zaraženy do RAID 1 poolu. Co skutečně se stalo na fyzickém disku, když po dešifrování předalo do filesystému checksum chybu nemám chuť zkoumat. Ten fyzický disk se pro mne tím pádem posouvá do kategorie "na výměnu". (On na to již má nárok. Je to totiž tento disk.)

smartctl -a /dev/sde
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.19.4-zen1-1-zen] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     SAMSUNG SpinPoint F2 EG
Device Model:     SAMSUNG HD154UI
Serial Number:    S1Y6J1LS806866
LU WWN Device Id: 5 0024e9 001feff7a
Firmware Version: 1AG01118
User Capacity:    1 500 301 910 016 bytes [1,50 TB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database 7.3/5319
ATA Version is:   ATA/ATAPI-7, ATA8-ACS T13/1699-D revision 3b
Local Time is:    Thu Sep  1 13:21:31 2022 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (19143) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 320) minutes.
Conveyance self-test routine
recommended polling time:        (  33) minutes.
SCT capabilities:              (0x003f) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   099   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0007   071   071   011    Pre-fail  Always       -       9430
  4 Start_Stop_Count        0x0032   098   098   000    Old_age   Always       -       1841
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   100   100   051    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0025   100   091   015    Pre-fail  Offline      -       11670
  9 Power_On_Hours          0x0032   086   086   000    Old_age   Always       -       73068
 10 Spin_Retry_Count        0x0033   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age   Always       -       1537
 13 Read_Soft_Error_Rate    0x000e   100   099   000    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0033   001   001   000    Pre-fail  Always       -       300
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       4
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   033   000    Old_age   Always       -       32 (Min/Max 15/35)
194 Temperature_Celsius     0x0022   068   032   000    Old_age   Always       -       32 (135 207 36 15 0)
195 Hardware_ECC_Recovered  0x001a   100   100   000    Old_age   Always       -       928398662
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       1141
200 Multi_Zone_Error_Rate   0x000a   100   099   000    Old_age   Always       -       1
201 Soft_Read_Error_Rate    0x000a   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6291         -
# 2  Extended offline    Completed without error       00%      2239         -
# 3  Extended offline    Completed without error       00%     61821         -
# 4  Extended offline    Completed without error       00%     61101         -
# 5  Extended offline    Completed without error       00%     60709         -
# 6  Extended offline    Completed without error       00%     53925         -
# 7  Offline             Completed without error       00%     52465         -

S nájezdem přes 73 000 hodin patří k mým nejstarším. Je zajímavé, že testy ani nepočítaly s tak vysokám nájezdem a přetočilo se jim 16 bitové numero. Poděkuji mu za dlouholeté věrné služby a vyměním ho v poli za novější disk. Vzhledem k flexibilitě souborového btrfs RAID1. tak třeba za něco takového jako Toshiba od Mironetu.

[lertimir]

Hm. trochu překlepové korekce "/dev/mapper/miraza je LUKS šifrovaný disk zařazený do RAID 1 poolu." a "..testy ani nepočítaly s tak vysokým nájezdem..."

[lertimir]

Ještě tomu odpovídá příkaz

btrfs scrub status /mnt/archiv
UUID:             d1722103-0c1e-4627-bbc7-9f1f0bf91739
Scrub started:    Thu Sep  1 00:00:47 2022
Status:           finished
Duration:         13:23:40
Total to scrub:   14.99TiB
Rate:             325.90MiB/s
Error summary:    csum=1
  Corrected:      1
  Uncorrectable:  0
  Unverified:     0

pomocí nichž si zkontroluji, jak scrub dopadl.

[trekker.dk]

Co skutečně se stalo na fyzickém disku, když po dešifrování předalo do filesystému checksum chybu nemám chuť zkoumat.

Ale s jistotou víte, že to byla chyba disku a ne chyba filesystému...

Protože tohle je na btrfs to nejzajímavější. Lidi tvrdí, jak jim scrub odhaluje jednu chybu za druhou. Dobrá, disky jsou nespolehlivé, vrací chybná data. Jak je možné, že jsem za ty roky nenarazil na něco, co by bylo rozbité? Špatně přečtený program bude dělat kraviny nebo padat, pokažený soubor nepůjde otevřít nebo bude obsahovat nesmysly... a ani na jedno z toho jsem ještě nenarazil. Při kopírování dat mezi disky dělám sha256sum na všechny přenesené soubory a vždycky všechno v pořádku. Před zálohováním dělám checksum souborů v záloze proti aktuálnímu stavu a vždycky všechno v pořádku.

Jako uznávám, že tam samozřejmě patří slovo zatím, ale podle toho, co tady nejen vy píšete, tak mě dávno měla postihnout totální apokalypsa.

[lertimir]

Proč totální apokalypsa? To co jsem napsal, že se mi objevila jedna chyba na 14 TB poli na disku, který má nájezd přes 70 000 hodin. A jsem rád, že to vím. Jaký ty máš use case netuším, ale hrát si při kopírování s sha256sum by pro mne připadalo náročné. Zkusil jsem se jen ilustračně kouknout kolik souborů mám a find / -type f | wc -l jelo 15 minut a nahlásilo něco přes 7 milionů souborů. Tahat si v desítkách tisiců adresářů soubory s hashy těch ostatních, nebo vytvářet nějaké jiné struktury mi připadá moc komplikované. (Systémová část etc,bin,usr,boot je samozřejmě hashovaná a kontrolovaná ještě přes rkhunter, ale to nejsou TB uživatelských dat.) Souborový systém s check sum integritu zařídí. Čistě pro ilustraci celkový součet obsazeného prostoru připojených souborových systémů na pracovní stanici, reportovaných df má 29831724820 kilobytových bloků (podle du -s 27703041088). Tedy málo přes 30TB obsazeno, 28TB skutečná data. (to 14TB pole z úvodu je v df jako 7337884672 obsazené bloky, protože je to RAID1). Chyby se mi objevují, je jich celkem málo, scrub mi umožňuje je mít pod kontrolou a vědět, kde nastávají. To je vše. Zase na rozdíl od jiných zpráv, jak btrfs havaruje se mi tohle nikdy nestalo, že by se nabourala struktura FS (nebo možná někdy před více než 10 lety) a spolehlivě ustál i několik mých silných chyb, jako třeba vypnutí prodlužky, když systém prováděl "poweroff", ale nevšiml jsem si, že ještě není dokončen, nebo vytržení externího disku během zápisu na něj.

A jsem v poslední době (cca 2 roky) i velmi spokojen s rychlostí btrfs, významně se zvýšila, jak přímá rychlost FS tak i úklidové operace, tedy když z FS překopírují několik set GB jinam, tak úklid b-stromů a opětovné získání a reportování prostoru na FS, je velmi rychlé.

[trekker.dk]

Psal jste:

A mohu ti potvrdit, že chyby check sumu se objevují. Pokud se začnou objevovat více

a teď:

co jsem napsal, že se mi objevila jedna chyba

a pak zase:

Chyby se mi objevují, je jich celkem málo

Tak jak to teda je? Objevila se vám jedna chyba, víc chyb, málo chyb...? Vyberte si. Já jsem každopádně reagoval na to první, co jste napsal: že se vám chyby objevují. Tak proč mně ne?

Tahat si v desítkách tisiců adresářů soubory s hashy

Od toho mám počítač, aby dělal repetetivní úkoly za mě. Aale / teda fakt neřeším, kdyby něco, tak tam jsou k dispozici nepoškozené zálohy v distribučním archivu balíků.

[lertimir]

No za asi 8 let stabilního používání se chyb odhadem objevilo tak cca 50-80, no a za tu dobu scrub přečetl odhadem jednotky PB. Tedy cca jedna chyba na 20-30TB dat čtených dat. Teď jsou dvě jedna na tom raid poli a jedna na 8TB jiném disku.

Od toho mám počítač, aby dělal repetetivní úkoly za mě. Aale / teda fakt neřeším, kdyby něco, tak tam jsou k dispozici nepoškozené zálohy v distribučním archivu balíků.

Ale přece o zálohu systému vůbec nejde. Záloha systému včetně snapshotů na btrfs před a po aktualizaci se tohoto vůbec netýká.

To proč se Vam neobjevují je Váš use case, třeba nemáte tolik dat, nečtete je pravidelně všechny, jsou v oblasti která není podstatná, chyba v multimedálním souboru někde uvnitř se může projevit i jen nepříliš výraznou změnou, zvláště když není na šifrovaných discích. Pak se bit flip jen projeví jako jednobitová změna a není blokovou šifrou roznesena do celého sektoru. Ale to není můj case.

[trekker.dk]

No za asi 8 let stabilního používání se chyb odhadem objevilo tak cca 50-80

No a to je ta apokalypsa, o které mluvím. Jestli vám za 8 let scrub našel 50-80 chyb, tak jaktože já jsem za tu dobu nenarazil na jediný chybný dokument, na jediný kravnoucí program, který by se přeinstaloval stejnou verzí a začal znovu fungovat, atd.

Ale přece o zálohu systému vůbec nejde.

Čtěte si to v kontextu. Reagoval jsem na vaši reakci na počítání checksumů před zálohováním, že máte v / miliony souborů - a já říkám, že kolik souborů mám v / mě vůbec nezajímá, protože když se nějaký poškodí, tak ho stáhnu znovu, tudíž nemusím řešit ani poškození, ani checksumy, ani zálohy. A ty počítám jen pro dokumenty, tj. /home apod.

[Andrej]

…tak jaktože já jsem za tu dobu nenarazil na jediný chybný dokument, na jediný kravnoucí program, který by se přeinstaloval stejnou verzí a začal znovu fungovat, atd.

Nic z tohoto↑ nelze s jistotou tvrdit ani vědět, takže jsou to všeho všudy kecy plus doufání v zázrak.

Jak se pozná, že binárka není poškozená, když FS nemá checksumy?

Proč by poškozená binárka musela nutně spadnout? Co když je poškozená tak, že nespadne, ale bude třeba zapisovat nebo odesílat nesmysly nebo přidávat šum do ukládaných médií?

…protože když se nějaký poškodí, tak ho stáhnu znovu…

Manuálně? Opravdu zaručeně a pokaždé? Kdy přesně? Jak se to poškození spolehlivě pozná? Kouzelnou hůlkou? Nebo křišťálovou koulí?

…tudíž nemusím řešit ani poškození, ani checksumy…

Tady↑ máme neporozumění realitě, Level Ultimate. Tohle snad ani není možné. Asi to bylo míněno jako vtip / recese / trolling.

A ty počítám jen pro dokumenty, tj. /home apod.

Jak je zaručená atomicita takových (téměř) manuálních rádoby-checksumů? Jak přesně jsou dokumenty chráněné mezi časem změny a časem aktualizace checksumu? A především: Proč vůbec explicitně a téměř manuálně dělat cosi navíc, co má dělat filesystém?

Sorry jako, ale tyhlety pseudoargumenty (stejně jako celý anti-Btrfs FUD) mají zkrátka holou prdel, jak už jsem psal výše.

[Velkej BOB]

Plky, plky. Používám 15+ let filesystémy ext* nebo xfs s mnoha TB dat a na žádnou záhadnou chybu jsem v nikdy nenarazil. Kontrolu dat mám denní nebo týdenní (kdysi tripwire teď AIDE). A když bylo něco na disku rozbitého tak to bylo vždy kernelem jasně hlášeno a i tebou proklínaný mdraid (1,5,6) mi to spolehlivě roky opravoval. Opět v kontrastu s tvýma apokalyptickýma závěrama. Používám i ZFS a BTRS a tam si teda můžu odpustit tu kontrolu externí kontolu checksumů (hashů), ale jistota je jistota (také žádný problém). To že jsem zažil rozsypané všechny ty filesystémy kvůli vadným diskům je také holý fakt, takže zálhoy jsou mnohem důležitější než na jakém FS ty data běží.

[trekker.dk]

Nic z tohoto↑ nelze s jistotou tvrdit ani vědět

Vy možná nedokážete rozpoznat, že dokument nelze otevřít, že obsahuje nesmysly nebo že program nefunguje, ale je mnoho lidí - odvažoval bych se říct, že většina - kteří to dokáží. Učte se, třeba to jednou zvládnete taky.

Jak přesně jsou dokumenty chráněné mezi časem změny a časem aktualizace checksumu?

Zkuste se zamyslet hlavou a přijdete na to. Hint: asi tak stejně, jako u toho Btrfs.

Proč vůbec explicitně a téměř manuálně dělat cosi navíc, co má dělat filesystém?

Protože momentálně neexistuje filesystém, který by to uměl a kterému bych zároveň byl ochoten svěřit data, o která nechci přijít/obnovovat je ze záloh. Plus to, že by to "měl" dělat filesystém, je taky vaše zbožné přání, není důvod, aby to nemohla dělat jiná vrstva.

[jiwopene]

Protože tohle je na btrfs to nejzajímavější. Lidi tvrdí, jak jim scrub odhaluje jednu chybu za druhou. Dobrá, disky jsou nespolehlivé, vrací chybná data. Jak je možné, že jsem za ty roky nenarazil na něco, co by bylo rozbité? Špatně přečtený program bude dělat kraviny nebo padat, pokažený soubor nepůjde otevřít nebo bude obsahovat nesmysly... a ani na jedno z toho jsem ještě nenarazil. Při kopírování dat mezi disky dělám sha256sum na všechny přenesené soubory a vždycky všechno v pořádku. Před zálohováním dělám checksum souborů v záloze proti aktuálnímu stavu a vždycky všechno v pořádku.

Jeden disk od Seagate mi tohle dělal. Pokud jsem ho zapnul, přečetl sektor, vypnul, zapnul a znovu přečetl, vrátil s trochou štěstí odlišná data. Asi záleží také na tom, co si kdo koupí a jak je to staré.

Disky od WD často odchází tak, že (odhadnuto poslechem) hýbou hlavičkou tam a nazpátek a IIRC po 120 s to vzdají a hodí chybu, kterou jistý OS/FS od jisté firmy zcela ignoruje, ale po těch 120 s je zatuhlý celý OS nebo aplikace. Jednou jsem se někomu takhle někomu zaposlouchal do zvuků dusíku a oznámil jsem mu, že mu odchází disk. Disk SMART test za svojí životnost viděl jen jednou a když jsem ho sputil, nahlásil chyby.

[jiwopene]

s/dusíku/disku/

[trekker.dk]

Disky od WD

... mi vzhledem k tomu, jaký mají firmware a jak jim "funguje" SMART, už nesmí do baráku.

Jinak to, co popisujete, AFAIK dělají disky do desktopů - u těch se počítá s tím, že to nemáte v RAIDu a že jediná šance, jak ta data zachránit, je přečíst je. Pokud si koupíte disk do datacentra (což bude stejné zařízení s jiným firmwarem), tak se tolik snažit nebude - ohlásí chybu a ať si to dořeší RAID.

[jiwopene]

Potom ještě bezpočet USB flashdisků, kde se něco podělalo a disk vracel nesmysly a při pokusu o zápis vrátil chybu. No a msdos filesystém to s radostí předal uživateli. Jeden takový uživatel to s překvapením zhodnotil slovy „proč je to zašifrované?“