Dotaz: Dojel jsem na BTRFS

[Jarda Misík]

Ignoroval jsem zdejší forum a před rokem nasadil po reinstalaci souborový systém BRTFS. Včera mi dosloužil. Mám stolní PC a když praskla v koupelně žárovka vypadl jistič v bytě i na chodbě. Po opětovném zapnutí PC nenaběhne a ssd disk rozdělený pouze boot fat32 a zbytek BTRFS je ze záchranných medií čitelný pouze fat32 oddíl a zbylá část je na totálku a nic z něj nedostanu. Nevadí, zálohy mám a vše snadno přeinstaluju, ale BTRFS na žádný disk nikdy více!!! S ext4 se mi to ta roky nikdy nestalo.

---

---

Odpovědi

[Jendа]

Co přesně znamená „nečitelný“? Nepomůžou různé ty btrfs-zero-log a tak?

Mně se zatím s btrfs vždycky děly různé podivnosti typu nedosažitelného jednoho souboru, něco nešlo přepsat atd., ale kompletně nepřipojitelný FS jsem ještě neviděl, alespoň ne do okamžiku než jsem spustil fsck a ten se rozhodl smazat /.

[Petr Tomášek]

Tak to jsi šťastný člověk. Mně dokázalo btrfs rozbít i jen upgrade jádra na novější..

Ty různé btrfs-zero-log a tak sice můžou někdy pomoci zachránit část dat, ale je to velmi vopruz a nikde pořádná dokumentace. U ext4 dám fsck a maximálně oželím pár dat, ale vím, že se fs nezčne rozpadat jak jádro ve Fukušimě...

[LarryL]

Mně dokázalo btrfs rozbít i jen upgrade jádra na novější..

Napsal jsi o tom blogový zápisek nebo dotaz do poradny, abychom si mohli přečíst detaily?

[Petr Tomášek]

Např.: https://www.abclinuxu.cz/poradna/linux/show/456601

[LarryL]

Napsal jsem ti tam odpověď. Jednalo se pouze o triviální falešnou chybovou hlášku v dmesg ve starším kernelu. Máš něco dalšího?

[czjaromir]

Nově jsem si taky nainstaloval btrfs. Mám to ale na discích v RAIDu. Tak doufám že když některý exne tak se to dopočítá.

[Petr Tomášek]

Mně btrfs zatím vždycky exnul na interní chybu konzistence, RAID nepomůže.

[xxl]

Mohl bys popsat, za jakých okolností k těm chybám konzistence došlo? Případně co to bylo za verzi kernelu/btrfs? Já tuším, že se tady už o tom mluvilo, ale nenašel jsem to.

[Petr Tomášek]

Různé verze od 4.9 po 5.10, a chyby:

• corrupt leaf při pokusu o přistoupení k nějakému souboru, po spuštění fsck se rekurzivně smazalo /. Tohle bylo hodně dávno (2015). Bylo to na notebooku který vozím na kole, takže lidi můžou tvrdit, že se třeba vyklepává RAMka.
• adresář který při ls -l udělá: ls: cannot access 'adresář/global.stat': No such file or directory, -????????? ? ? ? ? ? global.stat. Tohle bylo asi před rokem, kernel 5.9 nebo tak něco (ten FS stále používáme a adresář tam furt je, ještě nebyla příležitost to odmigrovat a udělat tam ext4). fsck hlásí chyby ale neodvážil jsem se pustit ho v ne-read-only režimu. Stroj je desktopový Ryzen s nVidia grafikou na kterém se trénují neuronky a různě to rozbíjejí. Lidi můžou tvrdit že za to může proprietární nVidia driver nebo obecná nestabilita hardwaru.
• ten stejný stroj ale jiný FS, jsou tam nějaké problémy že když se změní crontab tak rsync / /backups/ble spadne na permission denied že nemůže zapsat do destinace a pomůže rm toho souboru v destinaci. To je vlastně dobrý nápad se na to podívat, změnil jsem si crontab a uvidíme jestli v noci přijde mail.
• A poslední věc co se stala před měsícem, kernel 5.10:

  je rozbalancovaný, ale balance okamžitě spadne na ENOSPC i když jsem teď smazal 300 GB dat (z 1.2TB disku). Běží fsck, pak zkusíme https://www.suse.com/support/kb/doc/?id=000019789

  fsck žádnou chybu nenašel a po opětovném přimountování už to najednou fungovalo.

scrub nikdy nenašel žádnou chybu.

[xxl]

Díky.

Takže ke globální ztrátě dat celého fs došlo jenom tenkrát v roce 2015? A ty další případy byly méně závažné?

Tím fsck máš asi na mysli btrfs check?

Budeme doufat, že v roce 2015 jsi vyklepal ramku a že ostatní je opravitelné. A budeme zálohovat.

[Jendа]

Takže ke globální ztrátě dat celého fs došlo jenom tenkrát v roce 2015?

A navíc data šlo před spuštěním fsck odlít ven (až na ten jeden adresář což bylo něco nedůležitého v /var/tmp).

A ty další případy byly méně závažné?

Pořád je to minimálně opruz a downtime, protože to vyžaduje vyrobit FS znova a nalít tam zálohu. Oproti tomu když se mi nakoplo ext4 - to se samozřejmě taky občas stává - tak to fsck vždycky snadno dostal do konzistentního stavu a nebylo potřeba rsyncovat terabajt tam a zpět.

Tím fsck máš asi na mysli btrfs check?

Jo.

[LarryL]

Pořád je to minimálně opruz a downtime, protože to vyžaduje vyrobit FS znova a nalít tam zálohu.

Předpokládám, že vyrobit "FS znova" jsi musel pouze u toho selhání z roku 2015, protože u 2. odrážky píšeš, že "ten FS stále používáme". U 3. odrážky (rsync) píšeš, že se na to podíváš a u 4. odrážky jsi napsal, že "po opětovném přimountování už to najednou fungovalo.".

[Jendа]

protože u 2. odrážky píšeš, že "ten FS stále používáme"

Používáme s chybama :/

[LarryL]

Zkoušel jsi adresář (co tí hází tu chybu ls: cannot access 'adresář/global.stat') někam vykopírovat a nakopírovat zase zpátky, jestli se to tím nespraví?

Andrej psal, že takovou chybu zažil kvůli vadnému firmware SSD. Ty máš nějakou teorii jak ta chyba vznikla? Je třeba možné, že taková chyba vznikne chybou RAM (non-ECC), která udělá špatný checksum?

[Jendа]

Jenom jsem ho přesunul jinam a vytvořilo se znovu (je to nějaké postgresql tmp a lidi zdá se neměli problém když jim zmizelo). Kdybych ho teď smazal tak se možná FS „opraví“.

Říkám že checksum (scrub) sedí. Mohlo to být vadné SSD, bitflip v RAM nebo SW bug, a to ne nutně v btrfs, třeba nvidia driver někde něco přepsal, kdo ví.

[Jendа]

OK tak za to permission denied nemůže btrfs, ale rsync s --inplace volbou nemá rád když nemá právo pro zápis, i když běží pod rootem.

[Petr Tomášek]

Jakmile se btrfs jednou rozbije, je nejlepší - pokud máš dost kapacity jinde - data zazálohovat (případně obnovit ze zálohy) někam vedle a vytvořit nový FS.

Nedávno jsem měl případ, kdy se btrfs rozbil, nejprv to vypadalo OK, ale pak se to začalo rozbíjet víc a víc a pokaždé to s sebou vzalo (stará!) data. Naštěstí to pokaždé BTRFS vzdal a remountnul do r/o. Jenže pokaždé než to vzdal zařvalo pár dat.

[LarryL]

Nedávno jsem měl případ, kdy se btrfs rozbil, nejprv to vypadalo OK, ale pak se to začalo rozbíjet víc a víc a pokaždé to s sebou vzalo (stará!) data. Naštěstí to pokaždé BTRFS vzdal a remountnul do r/o. Jenže pokaždé než to vzdal zařvalo pár dat.

Napsal jsi o tom blogový zápisek nebo dotaz do poradny, abychom si mohli přečíst detaily?

[bigBRAMBOR]

tak tak, o čem není blogísek to neexistuje. A je dobré to takovým šumařům pořád opakovat aby věděli jací jsou zoufalci.

[LarryL]

Kdyby v blogísku byl i odkaz na bug report, tak by to bylo naprosto dokonalé.

[VoDo]

nikdy jsem nepochopil ten hajp okolo btrfs prijde mi to jako v praveku raiserfs to taky byla moda nez to zhaslo.

[Jesus Jimenez]

ReiserFS jsem pouzival roky a roky bez nejmensich potizi. Zhasnul kvuli uplne jinym duvodum.

[Max]

V dnešní době máš na výběr tyto FS:
1) ext4, kde rychle při větším zatížení dojedeš na spoustu věcí (statický počet inode a milion věcí okolo)
2) reiserfs, který je neudržovaný a patche posílá už snad jen jeden člověk, začíná být nebezpečné ho používat.
3) XFS, který v sobě má s každým kernelem spoustu změn, občas se tam objevují nepěkné regrese, nicméně stále nemá nemá snashoty a další pěkné fce.
4) btrfs, které je odladěné a disponuje konečně dlouho požadavanými fcemi.
5) ZFS, kde je problém s licencí a není ve vanille.

Jak to vidím já, pokud nebudeme počítat specializovaná nasazení, kde by dávalo smysl patchování kernelu a ZFS, tak tu máme dva použitelné FS, kterými je xfs a btrfs.
Všude, kde nepotřebuji snapshoty ani další fce a potřebuji lepší výkon, abych nemusel řešit overhead CoW, tak používám XFS. Jinak jedu BTRFS.

Dřív se dalo pochopit hejtování na BTRFS, protože spousta věcí nebyla dodělaná. V dnešní době to ale už moc nechápu.
Zdar Max

[Jendа]

V dnešní době to ale už moc nechápu.

Tak třeba jedna naprosto objektivní věc: jejich fsck má v manuálu velké varování že se nemá používat v ne-read-only režimu.

[LarryL]

Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.

Ty jsi zkušený uživatel, takže to používat můžeš. Je otázka jestli by tohle varování nemělo být u fsck všech FS. Mám dojem, že i ty sám jsi v nějakém komentu potvrdil, že fsck u ext4 ti může zahodit poškozená data.

[Petr Tomášek]

U jiných FS mi fsck ten filesystém spolehlivě opraví. U btrfs je reálné riziko, že jej ještě víc rozmrdá (bohužel, hovořím ze zkušenosti)...

[LarryL]

U btrfs je reálné riziko, že jej ještě víc rozmrdá (bohužel, hovořím ze zkušenosti)

Napsal jsi o tvé zkušenosti blogový zápisek nebo dotaz do poradny, abychom si mohli přečíst detaily?

[Max]

Nevím, fsck je riziko i u jiných fs. Docela bych se bál použít fsck na btrfs, né kvůli onomu fsck, al kvůli tomu, proč bych ho měl použít. Pokud tedy mám btrfs v nějakém divném stavu, tak fsck je ten nejmenší problém a spíš bych řešil, jak se to mohlo stát, zda nějaký bug v kernelu, nebo nějaká zrádná chyba v hw.
Pravdou je, že jsem skoro nikdy nepoužíval lowcost úložiště, takže se mě možná nějaké problémy, co způsobují odpadní disky, vyhýbají. Opravdu nevím :-/. Každopádně třeba notebook skoro nikdy nevypínám jinak, než natvrdo, bo je to rychlejší o několik vteřin, než když bych ho dal vypnout klasickou cestou (nepoužívám ho jako hlavní zařízení k práci, takže usínání zas tak často nepoužívám).
Zdar Max

[Pepa48]

K prvnímu bodu by na nějaké větší problémy s ext4 odkaz nebyl? Počet inode je stará známá věc a většiny uživatelů se nedotkne a navíc se dá nastavit. Dále bych se tě chtěl zeptat jako zkušeného uživatele jak si stojí BTRFS s COW s počtem TBW ssd disku oproti ext4? Stojím právě před rozhodnutím jaký fs na ssd zvolit a hodně by mi to pomohlo.

[Max]

U ext4 jde změnit počet inode, ale né online, je třeba přeformátovat. S narůstající kontejnerizací (docker apod.) se to začne brzo dotýkat i uživatelů. Jinak problém s inody jsem měl i na obyčejných web serverech.
Né, že by byl zabugovaný, ale architektura je prostě šíleně stará a dnešní doba si začíná sahat na limity.
Zdar Max

[xkucf03]

Zrovna jsem upgradoval resp. přeinstaloval systém a dal jsem tam:

/boot        ext4
/boot/efi    vfat
/            xfs
/mnt/data    btrfs

Snapshoty jsou pro mne dost důležité, pokud jde o datový disk. Proto Btrfs. Jinak jinak ho používám úplně jednoduše -- nad jedním blokovým zařízením, žádný Btrfs RAID. V tomhle jsem konzervativní -- RAID dělám přes mdadm a oddíly spravuji přes LVM. Mezi tím je ještě LUKS tzn. klasický vrstvený přístup, kdy každá vrstva dělá tu svoji jednu věc. Od FS nad tím tedy moc nechci -- v podstatě jen ty snapshoty, cp --reflink, kontrolní součty a ACL+XATTR (ale to mají dnes prakticky všichni).

Btrfs používám už řadu let, byť poměrně nenáročným způsobem. Zatím se mi to nikde nerozsypalo. Jednou mi btrfs scrub našel chyby u pár souborů, ale to považuji spíš za pozitivum (zřejmě tam něco uhnilo na HDD).

[Aleš Kapica]

V tomhle jsem konzervativní -- RAID dělám přes mdadm a oddíly spravuji přes LVM. Mezi tím je ještě LUKS tzn. klasický vrstvený přístup, kdy každá vrstva dělá tu svoji jednu věc. Od FS nad tím tedy moc nechci -- v podstatě jen ty snapshoty, cp --reflink, kontrolní součty a ACL+XATTR (ale to mají dnes prakticky všichni).

Míval jsem to kdysi podobně. A přechod na multidevice Btrfs byl ten nejlepší krok, co jsem udělal. Od té doby se ve službě tomuto FS vystřídalo už několik různě velkých disků. Píšu o tom hned o kousek níže. Tou nejpodstatnější výhodou pro mne je to, že drobný HW problém jako je např. to že zavadíš při výměně disku o kabel nevede v případě Btrfs k rozesrání a následně několikahodinové synchonizaci dat. To u MD raidu jsem se 9 hodin modlil, aby nevypadl proud. A to byly pěkně prosím jenom 2TB disky. Pole ve kterém jsou 8TB disky, bez jištěného napájení stroje, už jedině s Btrfs v raid1 módu a ideálně se dvěma replikama – to je budoucnost co mne čeká, až ten objem dat co na něm mám překročí těch 8TB.

Plánuji to spojit s upgrade počítače. Výhledově to znamená systém na 2x M.2 discích a data na 8x 8TB discích. Momentálně by to obnášelo investici cca 40 tisíc, kterou dám teď radši do zubů.

[Max]

Já to už mám. Jedu 2x NVME pro systém a pár věcí a k tomu mám 3x8TB s dvěma replikami na data.
Jinak s přechodem na multidevice jsem neměl žádný problém (technický, ani psychický), jakmile jsem mohl, použil jsem ho.
Zdar Max

[xkucf03]

Já s tím mám jednak ten „psychický“ problém (ve většině hororových příběhů o Btrfs figurovalo více disků tzn. nějaká forma RAIDu na úrovni Btrfs), takže to používám spíš tím opatrnějším jednodušším způsobem (podobně jsem nikdy nezačal používat RAID v LVM a radši jsem pod to dal MDRAID).

A jednak jde o to, že ty disky chci mít šifrované a pokud bych měl Btrfs (nebo jinému FS) dát dvě bloková zařízení, ať si nad nimi dělá RAID sám, tak by buď musel umět i šifrovat nebo by se všechna zapisovaná data musela šifrovat dvakrát – pro každý disk.

Takže jsem někde na půli cesty mezi nadšenými příznivci Btrfs a lidmi, kterým „tenhle FS nesmí na disk“. Nicméně netvrdím, že je to ideální – i když jsem obecně příznivcem spíš toho vrstveného přístupu, tak pokud by vše řešil FS, má to taky nějaké výhody. Např. pokud by mu neseděl kontrolní součet, tak by mohl zkoušet číst z obou (všech) diskům, jestli najde data, pro která ten kontrolní součet bude sedět. Nebo může synchronizovat jen části pole, na kterém jsou data. Případně je i šifrovat selektivně (ale kvůli bezpečnosti většinou budeme chtít šifrovat i volné místo). Nebo pokud jde rozumně vypínat CoW (chattr +C), tak FS může zastoupit roli LVM a efektivně sdílet volné místo mezi souborovým systémem a LV (protože LV jsou pak zase jen soubory).

[Max]

Něco šifrovat 2x nemám problém, používám železo, kde to nemá vliv na výkon. Tj. používám LUKS na blokovém zařízení a pak jej přidávám do btrfs. Na FreeBSD třeba ZFS neumělo šifrování, takže se donedávna používal podobný systém (GELI).
U mdadm nemusíš v případě nějakého triviálnějšího problému (náhodně vypadnutý disk, který znovu do pole vložíš) syncovat celé pole. Stačí, když si k mdadm generuješ bitmapu a syncne se ti pak jen rozdíl. Generování bitmapy (--bitmap=internal) má ale performance impact. Můžeš jí ale generovat na externí zařízení (třeba ssd, --bitmap=/mnt/mdadm/my_bitman.bin).
Zdar Max

[lertimir]

Souhlas RAID1 s btrfs je skvěle flexibilní. Mám btrfs RAID1 nad 5 disky, vzniklo to tak, že jsem postupně přidával disky a jen je zařadil do pole, takže tam je 1.5, 2, 3, 3, 4 TB, na železu je LUKS s klíčem na šifrovaném rootu, tedy 5 šifrovaných blokových zařízení a nad nimi jeden BTRFS RAID1 a vše bez problémů.

[Aleš Kapica]

Já s tím mám jednak ten „psychický“ problém (ve většině hororových příběhů o Btrfs figurovalo více disků tzn. nějaká forma RAIDu na úrovni Btrfs)…

Měl by sis víc všímat, kdo ty „hororové” příběhy vypráví.

[Bugsa]

No pěkné. Já se naštěstí na desktopu rozhodl pro XFS a již několik let zatím bez problému a to už pár takových výpadků taky zažil (ťuk ťuk na dřevo).

[czjaromir]

Tohle si nemůžu dovolit zdá se že si budu muset vytvořit ještě zálohu raidu.

[CyberPunker]

A prečo potom používajú spoločnosti ako Synology BTRFS systém ako default pri SHR napr?

[PetebLazar]

A je to ten nejsprávnější příklad? https://kb.synology.com/cs-cz/DSM/tutorial/What_was_the_RAID_implementation_for_Btrfs_File_System_on_SynologyNAS

[CyberPunker]

Souborový systém Btrfs se ukázal jako nejstabilnější komerční využití, ale byly vzneseny obavy z toho, že Btrfs RAID obsahuje chyby výpočtu parity, což vede k neobnovitelné ztrátě dat.

Takže tie chyby tám na 100 percent sú? Ako potom môžu dovoliť vývojári BTRFS používať tento FS na produkčných strojoch v RAID režime?

[PetebLazar]

Tam se zmiňuje že používají místo BTRFS RAID (ke kterému jsou výhrady) Linux RAID. Samotný filesystém (BTRFS) je až o vrstvu výše.

Cílem bylo pouze poukázat, že Synology řešení není čistě BTRFS(ZFS)-based, tj. kdy se i storage redundance na úrovní disků zajišťuje přímo v rámci nich.

[majales]

Pozor! Implementace btrfs na NASech značky Synology je nekompatibilní s linuxovou implementací. Nepodařilo se mi ze Synology použít "btrfs send" na linuxový server. Btrfs na Synology lze používat pro Synology software "Active backup for business", který slouží pro efektivní deduplikační zálohování Windows i Linux strojů.

[Jendа]

Synology je vůbec bizár.

[xxl]

Synology btrfs send má volbu --without-syno-features, při které je možné přenést snapshot mezi běžným linuxem a Synology linuxem.

[trekker.dk]

Ona je tady v podstatě jednoduchá otázka: jakou odpovědnost vůči vám Synology má, když kvůli chybě souborového systému přijdete o data? Odpověď je žádnou. Museli by použít něco hodně rozbitého, aby to postihlo dost lidí na hromadnou žalobu nebo nebo trestní řízení pro podvod, ale to je v podstatě jediné, co o tom filesystému říká jeho nasazení v domácích NASkách: není to úplná srágora.

[Andrej]

Z toho příběhu o žárovce mám dojem, že je to jen snaha o vyprovokování Andreje. Ale třeba jsem jen přehnaně podezíravý.

[Want]

Autor je blbeček, protože důsledek vydává za příčinu. Čert ví co se u něj stalo. Fakt jsem neslyšel o tom, že by vyhořelá žárovka vyhodila jistič. Spíš bych to viděl na proudový náraz který toho mohl sebrat mnohem víc. SSD není rotační disk.

[alkoholik]

Jistic mi vybavil kvuli praskle zarovce uz nekolikrat.

[xkucf03]

+1

P.S. A to mluvím primárně o klasických žárovkách. Ty "úsporné" jsou jiná kapitola - to je ještě větší svinstvo a dokáže to jističe vyhazovat dost ošklivě.

[Petr]

Autor je blbeček, protože důsledek vydává za příčinu. Čert ví co se u něj stalo. Fakt jsem neslyšel o tom, že by vyhořelá žárovka vyhodila jistič. Spíš bych to viděl na proudový náraz který toho mohl sebrat mnohem víc. SSD není rotační disk.

To co jsi napsal svědčí spíš o jisté znalostní zanedbanosti u tebe. Takže šup zpátky na základku do hodin fyziky a prostudovat jak funguje žárovka a jistič.

[LarryL]

Mně praskla žárovka mockrát a neuvědomuji si, že by mi to někdy vyhodilo jistič. Naposledy mi žárovka praskla před měsícem a jistič to nevyhodilo. Hádat se ale nebudu, možná že dnešní moderní jističe jsou citlivější. Jestli ale prasklá žárovka vyhodila tazateli dva dokonce jističe ("vypadl jistič v bytě i na chodbě"), tak to je fakt divné.

[dustin]

Prasklá žárovka mi jistič vyhodila spoustukrát. Je to běžná situace, podívej se do googlu.

[Want]

A,kolikrát ti to poškodilo FS?

[v.]

Tady je nějak spousta dojmů atp. Přidám vlastní zkušenosti. U řady ssd je poškození FS vlivem výpadku proudu prakticky jistota. Vychází to z principu zápisu dat. Pro oblasti s častějšími výpadky bylo lepší volit serverové ssd, které dokáží data dozapsat i po výpadku proudu. Nicméně i v případě "horšího" ssd se mně osobně ext4 vyrovnal se ztrátou přímo ukázkově. V dřívějších dobách byl z konvenčních FS nejhorší XFS, tam jsem zažil hodně potíží. Z modernějších se mi jednou sesypalo ZFS tak, že jsem to dával půl dne dohromady přes hromady "tajných" commandů, ale také se povedlo. No a na btrfs jsem nějak neměl odvahu to dlouho zkoušet, ale jako "vedlejší" FS na ntb fungoval dobře :)

[Want]

Jenže Btrfs není XFS. Je to COW systém, tzn. pokud dojde k výpadku proudu, nedojde k zápisu nových dat, ale ta předchozí budou tam kde byly. K tomu co popsal tazatel podle mne může dojít jen tehdy, když to sebere část paměťových modulů toho SSD. Kdyby to vzalo elektroniku, co ty data rozsypává, tak nepřečte ani tu FAT.

[Jendа]

Disk si mohl zpřeházet zápisy (metadat) kolem bariéry a část z nich při výpadku nedokončit.

[Petr Tomášek]

Jasně, do té doby, než se BTRFS totálně pomátne (rozpadne se mu stromová struktura) a začne náhodně zapisovat na místa, kde už jsou starší data, LOL.

[Andrej]

Zajímavé je, že se takové věci stávají zrovna tobě. Jestlipak to není znamení shůry, aby ses nesral do věcí kterým nechceš porozumět?

[Petr Tomášek]

Člověče, s tebou je ještě větší sranda než se Svědkama Jehovovama nebo s veganama. „Pak věříš špatně, když jsi nemocný...“, „Děláš ten veganismus špatně, když ti zdravotní problémy přibývají a ne ubývají. Vlastně jsi nikdy vegan nebyl...“

Takže tu máme BTRFS-Sektu, krom veganů, svědků jehovovových, muslimských bratrstev a já nevím koho ještě, LOL...

[LarryL]

než se BTRFS totálně pomátne (rozpadne se mu stromová struktura) a začne náhodně zapisovat na místa, kde už jsou starší data

Napsal jsi o rozpadnutí stromové struktury a o náhodném zapisování blogový zápisek nebo dotaz do poradny, abychom si mohli přečíst detaily?

[frufru]

příběhu o žárovce - klasická, nebo úsporná? Úsporná - zářivka, nebo led? On je v tom docela rozdíl.

[czjaromir]

Každá žárovka může zkratovat. Například ta s klasickým vláknem vlivem tepelného pnutí praskne. Následně se dostane dovnitř vzduch a vlákno shoří, jeden z důsledků je krátkodobě zvýšený proud který vyhodí pojistky.

[Andrej]

Máš pravdu je jich více druhů. Jsem zvyklý, že když se mluví o žárovce, tak se tím myslí ta klasická s vláknem, které se už nemohou prodávat. U těch se většinou jen po čase přepálilo vlákno, obvod se přerušil a žárovka zhasla... ale jistič (alespoň v mém případě) to nevyhodilo.

Důvod proč si myslím, že příspěvek je jen snahou o vylákání Andreje je to jak je celý ten příběh napsán: Praskla žárovka ... btrfs je na totálku ... ale nevím pořádně co se stalo ... nástroje co jsem použil na obnovu raději zamlčím ... ext4 je každopádně nejlepší.

Příliš podivný příběh.

[frufru]

Tady je vidět, co vlasně v té žároce je. https://www.youtube.com/watch?v=5CkDgdvwZ_4

[LarryL]

No jo no, LEDky. A přitom s klasickou žárovkou byla taková legrace. Třeba šla potopit do kapalného dusíku https://youtu.be/VtjYSAQkfdM?t=128

[R]

Mal si stastie na ziarovky...

Obcas to skonci inak: po zapnuti svetla zablesk, rana, kusy skla po celej miestnosti a vsade tma. Istice vyrazene az vonku. V lampe zostane zo ziarovky len zavit, ktory sa dost blbo vytahuje (kliestami). Nasledne zistis, ze svetlo nejde vypnut, lebo sa zvarili kontakty vypinaca :D

[LarryL]

Obcas to skonci inak: po zapnuti svetla zablesk, rana,...

Až tak nebezpečné jsou moderní LED žárovky? Já mám pořád ještě klasické staré žárovky kde nemá co vybuchnout.

[LarryL]

...možná halogenky nebezpečně vybuchujou: Výbuch žárovky

[LarryL]

...aha tak možná i klasické výjimečně bouchnou. Tak teď budu mít trauma při každém šáhnutí na vypínač, a přitom do teď jsem měl tak klidný život

[X]

Klasicke zarovny ksem pouzivaůl 40 let, ale tohle se mi nikdy nestalo :)

[Max]

Ono záleží na elektroinstalaci. Tj. jak kvalitní máš rozvod, jak je vysaturovaný, jaký tam máš jistič apod. Pokud by jsi měl mít vše podle předpisů, tak je opravdu velmi malá pravděpodobnost, že by to jistič shodilo.
Zdar Max

[čavo]

Klasická žiarovka prakticky vždy končí na to, že sa jej roztrhne (prepáli) vlákno. Potom už len ide o to čo sa stane s tým voľným koncom. Ak je zrovna tak pootočená tá žiarovka, že sa voľný koniec dotkne živej časti tak, že sa vlákno skráti, prudko sa zníži odpor vlákna a snaží sa ním prejsť (ako aj celým obvodom) podstatne väčší prúd ako obyčajne. Efekty sú zaručené.

• záblesk, väčsinou veľmi krátky
• možné prerušenie obvodu na ističi (poistke)
• možnosť prasknutia žiarovky z dôvodu prehriatia

[lertimir]

Souhlas, když jsem před lety používal žárovky, také se mi několikrát stalo, že žárovka vyhodila jistič, a někdy výjimečně i hlavní (25A). Vždy se to stalo při zapnutí, což si představuji fyzikálně tak, že po čase provozu se vlákno díky vypařování v jednom místě ztenčí více než jinde. Každým novým zapnutím se nerovnováha zvětšuje, protože ztenčené místo se rozehřeje rychleji a na vyšší teplotu než zbytek a vypařuje se rychleji.

[dustin]

Domnívám se, že to může souviset i s okamžitou amplitudou napětí v okamžiku sepnutí.

[Pepa]

tak pokud jste měl místo jističů hřebíky tak věřím Ale vážně docela záleží na kvalitě vlákna žárovek, na selektivitě jističů (neměl by vybavit hlavní) a na typu rozvodu v bytě, zda je to TNC(dvojvodičový) nebo nový TNS(třívodičový). Rozvody s hliníkovými dvojvodiči (TNC) se selektivita nikdy moc neřešila.

[Jendа]

Já teda jističe vyhozené žárovkou potkával a naopak nežárovky (typicky se spínaným zdrojem) umírají bez speciálních efektů.

[Petr]

které se už nemohou prodávat

fakt, kde to zijes?

[LarryL]

Už jsem byl poučen, že se prodávat mohou, teda nemohou, ale prodejci si našli cesty jak zákaz obejít. Mám doma zásobu klasických žárovek, takže jsem neměl důvod se v obchodech dívat po žárovkách.

[_]

nektere typy se prodavaji zcela bez omezeni

u tech, co omezeni maji, staci deklarovat, ze to neni svitidlo ale topidlo, a take se jako topidla tradicne pouzivaji (treba pri chovu hadu)

[lertimir]

Naopak, ony se dokonce pro některé použití prodávat musí. Např. kdekoli jsou točivé stroje, nesmíš mít světelný zdroj, který mění intenzitu světla, protože bys mohl mít stroboskopické efekty a vidět, co není a je ohrožující. Na soustruh si ledkou svítit fakt nedoporučuji.

[Jendа]

Já jsem na blikání velmi citlivý, ale i většina „LEDek a zářivek do E27“ moc nebliká (některé blikají); většinou si ale svítím tak, že LEDky/LED pásky napájím pomocí stabilizovaného DC zdroje - a ten zvlnění fakt nemá, výrobce musí garantovat, že se tím dají napájet počítače a další elektronika. Nejlepší jsou takové ty různé plechové nebo DIN lištové MeanWelly (LRS-75-12, EDR-75-12). Stojí to pětikilo, IMHO naprosto úžasná cena za takové zařízení.

[_]

vetsinou blikaji na frekvenci, ktera je zcela mimo schopnosti lidskeho oka

[P.]

co to je za dotaz? Zcela jistě se jedná o klasickou žárovku s vláknem. Úsporka nebo Led-ka v drtivé většině jistič nevybaví.

[pepe_]

Hlavně když praskne žárovka a vyhodí jsitič tak pc má jet dál protože světelný a zásuvkový okruh musí mít každý vlastní jištění.

[Jendа]

Jističe nejsou selektivní (typicky jsou selektivní do 90A), takže pokud vznikne zkrat hodně natvrdo, může vybavit kterýkoli jistič po cestě.

[lertimir]

Nebo někdy také se vybaví všechno. Měl jsem starou rozbrušku určenou k vyhození, kamarád si ji prohlížel a napadlo ho, že ji zkusí vrazit do zásuvky a zapnout, a než jsem mu v tom stačil zabránit tak to provedl. Spadl jistič zásuvek pro místnost (16A), proudový chránič pro zásuvky v patře (30mA), celodomní protipožární proudový chránič (300mA), hlavní 3F jistič (25A). A byl jsem moc rád, že neshořela 30A tavná pojistka na sloupu.

[Max]

Jak zní otázka? Toto je poradna. Pokud chceš volnou diskusi, použij blog. Pokud otázku nemáš, thread zamknu, jelikož jakákoli další diskuse je bezpředmětná.

Pro diskutující.Téma žárovky je úsměvná. Samozřejmě, že vadná žárovka může vyhodit jistič. A je jedno, o jaký typ žárovky jde. Samozřejmě záleží i na elektroinstalaci jako takové. Dále obyčejné žárovky se stále smí prodávat a také se prodávají (jak v eshopech, tak v kamenných prodejnách). V dnešní době ale o ně moc lidí zájem nemá, navíc i spousta nových zařízení není s klasickými žárovkami kompatibilní (mají totiž limity alá 40-60W na celý lustr apod.)

Pokud jde o ono hypotetické poškození btrfs, tak výpadek proudu opravdu btrfs nepoškodí. Co jej může poškodit, to je firmware ssd disku, kdy consumer ssd disky nemají ochranu dat v případě výpadku proudu. To mívají jen enterprise disky. Osobně mám zkušenosti, že firmware ssd disku takto poslal do nebe nemálo věcí.

Pokud jde o Synology, tak ti implementovali btrfs nad mdadm. Důvodů bylo podle mě několik. Jednak řešení SHR, dále dřívější stabilní implementace RAID5/6 v mdadm. Dříve absence RAID1CX u btrfs atd.
Ta hypotetická chyba ohledně výpočtu parity se týká jen RAID5/6. Tento typ pole navíc dnes provozuje jen blázen, jednak protože tragický výkon, dále tu už konečně máme RAID1Cx. Jinými slovy, RAID1 implementace v BTRFS je bezproblémová / nejsou známy problémy. Osobně BTRFS už jedu skoro všude (Synology, ntb, pc, home server, dříve firemní storage atd.).
Zdar Max

[czjaromir]

Tak to by mě zajímalo jaký mám RAID protože nějak jsem znejistil. Tohle mi vypíše mount /dev/md0p1 on /media/jaromir/4e98b7ce-bf5a-4010-98d4-a46a90e9e65e type btrfs (rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/,uhelper=udisks2)

[Jendа]

Máš mdraid, cat /proc/mdstat

[czjaromir]

mám tři disky a nevím jestli je to raid 4 nebo 5 či jiný.

[PetebLazar]

RAID4(paritni informace na vyhrazenem členu) údajně v tomto miléniu nebyl nikde pozorován, takže bych si tipnul že půjde o RAID5(paritni informace jsou na vsech clenech).

[k3dAR]

v zminovanem /proc/mdstat na radku zacinajici md0 mas "active raidX"

[czjaromir]

Díky za nakopnutí

root@Uloziste:/# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md0 : active (auto-read-only) raid5 sdc1[1] sdd1[2] sdb1[0]
      3906762752 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 0/15 pages [0KB], 65536KB chunk

[LarryL]

Co jej může poškodit, to je firmware ssd disku, kdy consumer ssd disky nemají ochranu dat v případě výpadku proudu.

Můžeš to trošku rozvést nebo dát odkaz na nějaký článek? Které konkrétní SSD ti odešly do nebe po výpadku proudu? Rád bych se takovým SSD vyhnul.

[Max]

Byly tím proslulé Crucial M4. Byly to vyhlášené disky jako držáky s výborným výkonem. Později se přišlo na to, že disk odejde při určité konstelaci po výpadku proudu. Jinak kromě toho, že jsem o tom slyšel, se to i kolegovy stalo.

Jinak to, co cituješ, nesouvisí s odchodem disku do věčných lovišť. Souvisí to jen s konzistencí dat. Problém může být patrný v případě, kdy k výpadku dojde při větším zápisu. Ochrana proti tomuto se nazývá "Power-loss data protection". Tady máš nějaké pdf k přečtení:
Intel_SSD_320_Series_Enhance_Power_Loss_Technology_Brief.pdf
Micron-ssd_power_loss_protection_white_paper_lo.pdf
a tady zajímavý thread v TrueNAS foru:
List of SSDs with Power Loss Protection.
Zdar Max

[Bugsa]

Také jsem ho měl v kapacitě 128 GB jako své první SSD a je to pravda. Ale naštěstí se dalo oživit nějakým postupem s vypínáním/zapínáním napájení. A po upgrade firmware se problém už nikdy neobjevil a to se mnou prošel několik notebooků a desktopů a doteď funguje v darovaném PC... Takže životnost má parádní.

[LarryL]

Jinak to, co cituješ, nesouvisí s odchodem disku do věčných lovišť. Souvisí to jen s konzistencí dat. Problém může být patrný v případě, kdy k výpadku dojde při větším zápisu. Ochrana proti tomuto se nazývá "Power-loss data protection".

Takže tohle je ten méně závažný problém kdy "pouze" dojde vlivem ztráty napájení ke ztrátě dat v bufferu SSD. Předpokládám, že s tím by si měly fsck ext4 i btrfs poradit. Btrfs asi bude více řvat (obtěžovat uživatele hláškami). Ext4 si to opraví tím způsobem, že uživatel většinou ani nepostřehne, že o data přišel. Chápu to správně?

Byly tím proslulé Crucial M4. Byly to vyhlášené disky jako držáky s výborným výkonem. Později se přišlo na to, že disk odejde při určité konstelaci po výpadku proudu. Jinak kromě toho, že jsem o tom slyšel, se to i kolegovy stalo.

A jestli správně chápu, tak tohle je jiný závažnější problém kdy se po ztrátě napájení může ztratit celý disk. Následně se musí provést resuscitace SSD způsobem, který je popsán např. zde:

Crucial recommends that M4 owners whose drives suddenly vanish simply let the drive sit for some 40-60 minutes with the SATA connector disconnected, but the power cable still connected....

[Max]

To, že disk zmizí a nejde připojit, beru jako poškození. Když za to může zjevně firmware, beru to jako poškození vlivem firmware. Co si pamatuji, kolegovi se ten disk oživit nepodařilo. Nicméně řešil to jen on a těžko říci, jak byl v té době zkušený googlitel. Vím jen, že našel lidi, kterým se to také nepodařilo. Každopádně na trhu jsou hodně levné noname ssd disky a nedělám si iluze, že jejich fw bude na špici. A lidi to kupují. Věřím, že Crucial nebo Samsung se postupně už vším vytrestaly a fw i hw zdokonalily. Nevěřím ale, že noname čína bude na podobné úrovni. Tj. podobné riziko zde podle mě pořád někde bude.

Pokud jde o ztrátu dat, které byly potvrzeny, ale nebyly zapsány, tak záleží, o jaká data jde. Osobně neznám žádnou ukrutně velkou náhodu v takové konstelaci, že by to totálně rozsypalo FS (na to by bylo potřeba znát daný fs včetně všech procedur, které kernel dělá, tj. nějaký nízkoúrovňový developer). To ale samozřejmě neznamená, že neexistuje. Třeba to jsou právě ty malé střípky, které se občas někde objeví, když někdo na nějaký fs nadává a ostatní, co ho používají sto let bez problémů, se dotyčnému jen nechápavě diví a považují ho za hejtra,
Zdar Max

[alkoholik]

FW stoji porad za starou belu.
Samsung SSD 980 ma chybku, ktera hlasi false positive teplotni spicky 85˚C. Opravili to az v nejnovejsi verzi. V linuxu byl flash noveho fw celkem oser.
WD Blue SN550 ma spatne tabulku sporicich rezimu a kernel kvuli nim panikari. Flash je bohuzel mozny jenom ve Windows.

[Host]

Můžeš pls uvést nějaké detaily k flashovani? Jsem majitel Samsung SSD 980 500GB a hlásí mi to občas 84˚C, dík

[Max]

Toto Trying to update a Samsung 980 Pro 1TB mi nepřijdě nijak složité. Stáhneš offiko iso a ručně spustíš update tool.

Jinak můžeš tam mít False positive a nemusíš. Pokud nemáš plácnutý pasiv na NVMe disku a nemáš nějaký průtok vzduchu skříní, tak to při zápisech může opravdu podobné teploty saturovat a není to ideální. NVMe disky topí jak čert pod kotlem.
Jejich umístění těsně u GPU tomu také moc nepomáhá.
Zdar Max

[alkoholik]

V tom navodu chybi jeste bind mounty a chroot /tmp/fwupdate.

[LarryL]

To, že disk zmizí a nejde připojit, beru jako poškození. Když za to může zjevně firmware, beru to jako poškození vlivem firmware.

Souhlas.

Pokud jde o ztrátu dat, které byly potvrzeny, ale nebyly zapsány, tak záleží, o jaká data jde. Osobně neznám žádnou ukrutně velkou náhodu v takové konstelaci, že by to totálně rozsypalo FS

Andrej popisoval rozsypání FS, cituji:

Před lety jsem měl SSD s firmwarem nekompatibilním s Linuxem, který dělal cosi neobvyklého při uspání. Systém následně vypadal jako hrad Trosky. Po cca 20+ násilných restartech z nevysvětlitelného stavu systému se tohle stalo — v nějakém adresáři bylo pár položek se stejným názvem.

Zdá se tedy, že firmware SSD dokáže více či méně rozbít FS. Dobré vědět. V tomto směru se dá pochopit, že btrfs bude mít mezi domácími uživateli více hejterů než ext4, protože dostat do konzistentního stavu komplexnější FS jako je btrfs bude pro domácího uživatele složitější. Domácí uživatel ocení hlavně to, že počítač nějak nabootoval a když po čase zjistí, že něco nefunguje, tak to možná ani nedá do souvislosti se ztrátou dat, ale bude si myslet, že mu to rozbila nějaká aktualizace.

[lertimir]

Podle mne je tam ještě jeden hráč, a to zdroj. Před několika lety, když si ještě osobně nebyl vědom jak důležitá je kvalita zdroje, jsem měl jeden levnější Fortron v domácím počítači. A jednou se mi stalo, že jsem velmi pospíchal, vypnul počítač a odcházím a v tom jsem zjistil, že jsem dal reboot místo poweroff, systém byl v té chvíli kousek za grubem, tuším četl initramfs nebo jádro, tak jsem ho vypnut natvrdo vypínačem na zdroji. Což může být podobné, jako výpadek jističem. Zdroj mi odstřelil procesor a motherboard. Asi v té situaci "pod zátěží" tam poslal nějakou špičku. Od té doby jen kvalitní zdroje Enermax, Seasonic ve vyšších konfiguracích.

[Petr]

Moc se tu roztahuješ, tohle není tvůj osobní server.

[Max]

Přečti si pravidla poradny. Je to poradna, né volná diskuse. Od toho vždy byly blogy.
Zdar Max

[trekker.dk]

A přesto jste si do té ne-volné diskuze přisadil se svým příspěvkem

[Max]

Toho jsem si samozřejmě všiml :)
Zdar Max

[PetebLazar]

Pokud se snad někdo v blozích na něco zeptá, máme ho odkázat na Poradnu? I když to se tam asi nikdy nestane, tam ví každý všechno nejlépe dvakrát.

[Max]

Nerozumím, co je nesrozumitelného na pojmu "volná diskuse"?
Zdar Max

[_]

proste zalez

[Pepa-dtm]

Před časem jsem byl zvědavý a nasadil jsem na stolní PC bez ups-ky fs BTRFS. Celkem veliká spokojenost a žádné problémy. Zazálohovaná data a tak jsem zkusil vypnutí pc síťovým vypinačem. Dopadlo to opravdu špatně. Asi 2x sice PC naběhl, ale s ohromnou spoustou chyb a nabíhal dlouhou dobu. V ostatních případech nenabootoval. Vždy jsem vše obnovil pomocí Clonezilly.

Povedlo se mi však problém jednoduše vyřešit. Použil jsem ze šuplíkových zásob elektrolytický kondenzátor 33G/16V kdy jsem kladný pól připojil přes odpor 68 ohm na plusovou větev 12V zdroje. Paralelně k odporu jsem připojil 10A diodu v nepropustném směru. Te odpor tam je z opatrnosti aby při zapnutí zdroje nevznikl velký proudový náraz. Při přerušení síťového napětí chvilku teče přes diodu proud z kondenzátoru a v mojem případě se fs BTRFS nezbořil. Zkoušel jsem jak ssd tak i plotnový disk u kterého je pěkně slyšet zpomalený doběh.

Moc tomu nerozumím jak o chvilku delší napájení zabrání rozhození BTRFS fs ale pokaždé systém normálně bez problémů naběhne.

[Aleš Kapica]

No dělal jsem už všelijaké kejkle, ale nic podobného nezažil.

Naposledy teď o víkendu. Na domácím úložišti (obsazeno cca 7TB) byl Btrfs raid1 nad 10x 2TB rotačními disky (2x 3,5” Seagate + 1x 2,5” Samsung + 2x 2,5” Seagate + 5x 2,5” Toshiba). Protože můj postarší matherboard má jen 6 SATA portů, byly potřeba ještě dva starší řadiče. Celkem tedy bylo k dispozici 14 SATA pozic. Tak vysoký počet konektorů a SATA kabelů však sebou přináší riziko chyb, co vznikají třebas jenom tím, že se některý z konektorů časem uvolní. Logicky se tedy můžete ptát: „Proč tolik disků?

Pro vysvětlení je třeba jít do minulosti. Součástí původní konfigurace stroje byly 4x 2TB 3,5” Seagate (dva z těch disků jedou bez sebemenší chyby dodnes). Ale když jsem se s daty dostal na 3TB, nebyly chladiče HDD které používám k sehnání.

Zkrátka, původní plán byl, že koupím box na 12x 2,5”, 16 portový řadič a přejdu komplet na 2,5” disky. Jenže začala divná doba. Objevily se první SSD a SHDD disky. Začaly mizet 2,5” disky se 7200 otáčkami a maximální kapacita klasických rotačních disků, bez ohledu na velikost, byla 2TB. Rozhodl jsem se tedy vyčkat.

Příznivá konstelace nastala nyní. V duchu původního plánu jsem se rozhodl časem nahradit rotační disky za SSD, proto mi přišlo zbytečné kupovat další 2,5” rotační disky a raději jsem zvolil 2x 3,5” 8TB Seagate, abych mohl vyhodit z pole dvě Toshiby, které začaly ve smartu vykazovat chyby. Koupil jsem tedy (konečně) i ten řadič. Byl jetý, ale to ty dva starší také takže jsem nějakou zradu neočekával.

Vše jsem zkompletoval, přidal nové disky do pole a začal přesouvat data z problémových disků. Jenže ouha! Asi po dvou hodinách přestal jeden z těch disků komunikovat. Proto jsem přesun přerušil a pro jistotu stroj vypnul. Jenže při novém startu už řadič neviděl žádný disk. Vrátil jsem se tedy pokorně k původní konstelaci. Bylo to na fous, protože bylo nutné využít komplet všechny SATA porty. Ukázalo se, že ten 8TB disk je ok. A veškeré operace se podařilo bezchybně dokončit.

Jinak k tomu co píše Pepa-dtm: Asi 2x sice PC naběhl, ale s ohromnou spoustou chyb a nabíhal dlouhou dobu.. To je u Btrfs v raid1, které se ustřelí vypínačem normální. Vypisuje ty chyby, ale zároveň je řeší. A systém nenajede, dokud není FS OK. Většinou jde o to, že nahrazuje chybějící chunky, které se díly náhlému přerušení proudu nestihly uložit.

Také jsem nepostřehnul jakou kombinaci disků Pepa-dtm použil.

[lertimir]

Podle mne je to o špatných zdrojích, které tam při fyzickém vypnutí pustí bůhví co. Mnohokrát jsem natvrdo vypnul komp dlouhým podržením předního vypínače a nikdy se s btrfs nestalo nic. A jak jsem už psal zde, špatný zdroj mi zabil komp. Trochu jsem podezříval i pasivní PFC, o němž si myslím, že když se v špatném okamžiku vlny vypne, tak tam pošle šlehu.

[Pepa-dtm]

Souhlasím, kdyby byl zdroj osazen většími kondenzátory nemusel bych praktikovat takovou opičárnu. Až se mi dostane do ruky jiný zdroj znovu to zkusím. Asi je BTRFS citlivější než ext4 na tyto případy, ale i pomocí hw se to může vyřešit řešit

[Aleš Kapica]

Asi je BTRFS citlivější než ext4 na tyto případy…

Houby s octem. Btrfs ti akorát na rozdíl od ext4 řekne, že našlo problém, který bylo potřeba vyřešit.

Jinak kvalitní zdroj je základ počítače. Kdo na něm škudlí je vůl co si zadělává na problémy.