Dotaz: Problém s disky v RAID 1

[Gustav]

Zdravím, včera jsem se definitivně rozhodl opustit Windows 10 a zároveň celý Microsoft. Nebylo to lehké rozhodnutí a věděl jsem, že to bude v Linuxu težké. No ale k věci, v biosu jsem vytvořil RAID 1 a celou dobu jsem ho ve Windows používal, dneska jsem nainstaloval Linux a vidím oba dva disky v RAID a nevím na který mám tedy ukládat data, ve Windows jsem viděl pouze jeden disk :( Poradí někdo ?

Odpovědi

[Jooky (inactive)]

Ten raid v biose ja s velkou pravdepodobnostou tzv "fake raid". Jedine co spravi je, ze povie windows ovladacu ako ma s diskami pracovat. V pripade raid 0 maximalne natiahne loader.

Doporucujem ten raid vypnut a pouzit sw riesenie v Linuxe (mdadm). Pri pouziti Linux raidu bude nad nim aj lepsia kontrola. Popripade ak si na to trufas, tak nahod btrfs v mode mirroringu.

Btw. Co je to za dosku ? Podla typu a vyrobcu sa snad bude dat najst co to je za raid ...

[Gustav]

Btw. Co je to za dosku ? Podla typu a vyrobcu sa snad bude dat najst co to je za raid ...

MainBoard specifications

No, jak to tak čtu, je to složitější než se zdálo

[k3dAR]

a s vedomostma kolem windows jsi se uz narodil? ;)

[Gustav]

A jaké pak potřebuješ vědomosti ve Windows ? Otřepané fráze linuxáků. Když se tady na něco člověk zeptá, tak dostane radu, kterou ihned dalších x lidí vyvrátí, hádáte se tady jak malí kluci a já vím stejně jako jsem věděl když jsem pokládal dotaz, čili nevím nic. Nejde mi RAID, netisknu, klávesnice spíš nefunguje jak funguje, 3 x za hodinu na mě vyskočí okno "že se něco podělalo", rozlišení monitoru mám tak malé, že ikony rozeznám i když jsem na dvoře a nastavit větší nelze, spotřeba o 70 watů vetší než u Windows, ventilátory jedou pořád na doraz, oblíbené programy nespustím, telefon nepřipojím a to u toho sedím první den. Kolik času je potřeba vše zprovoznit ? Měsíc ? Rok ? Nikdy ? Mám někoho zavolat aby mi to za 5 000 nastavil ? Zálohování, v dnešní době neexistuje funkční řešení jak vytvořit bitovou kopii disku aniž bych musel vypínat PC a načítat nějakou otřesnou CloneZillu která ve finále zálohuje šifrovaný disk 3 hodiny ? Nechápu jak může někdo srovnávat Windows a Linux, jsou to absolutně zcela odlišné věci. Hlavně, že je plná prdel toho, jak přejděte z XP na Linux, navíc je zdarma. Tak to je pádný argument, proč neexistuje placený Linux ? Já za něj klidně 3, 5, 8, 10 tisíc dám, dal jsem to za Windows tak proč ne za funkční Linux. Čeština, otřes, ani ta základní pitomá instalace není celá v češtině, každý anglicky neumí a já už se to v 55 letech učit fakt nebudu. Je tady opravdu někdo, kdo používá výhradně a pouze Linux na něco jiného než brouzdání po internetu ? Já vezmu 60 let starou slivovici a přijedu se podívat, jelikož tomu fakt nevěřím! Nevím co mám dělat, šmírácký Windows u mě skončil, definitivně a Linux nefunguje, zbývá už jenom Apple s HW o hovně za 60 000. To jsme dopadli.

[Jendа]

A jaké pak potřebuješ vědomosti ve Windows ?

V tomto konkrétním případě asi žádné. Až se ti deska rozbije a budeš chtít přečíst disky v jiném počítači, tak vědomosti génia.

Když se tady na něco člověk zeptá, tak dostane radu, kterou ihned dalších x lidí vyvrátí

Protože neexistuje jedno řešení tvého problému, ale minimálně tři, přičemž mají různé výhody a nevýhody.

Kolik času je potřeba vše zprovoznit ? Měsíc ? Rok ? Nikdy ?

Já měl na hardware štěstí, takže mi všechno fungovalo už tehdy. Pak mi zlobil power management u nového notebooku, ale šlo vygooglit řešení a v další verzi distribuce to opravili. Co se týče času, tak myslím, že člověk se může stát skutečným linuxovým guru tak po 5 letech každodenního používání a studování.

Jinak já měl tebou popisovaný pocit když jsem poprvé sedl k Linuxu taky a teď mám ty stejné problémy když se musím starat o Windows.

netisknu

Google: název tiskárny + linux. Případně se podívej do webového rozhraní CUPSu na http://localhost:631, jestli to tam nepůjde snadno naklikat.

klávesnice spíš nefunguje jak funguje

?

rozlišení monitoru mám tak malé, že ikony rozeznám i když jsem na dvoře a nastavit větší nelze

Koukni do /var/log/Xorg.0.log, jestli tam není nějaká závada, kvůli které to používá VESA ovladač. Nemáš jiný nainstalovaný, nefunguje ti kernel mode setting nebo tak něco.

spotřeba o 70 watů vetší než u Windows, ventilátory jedou pořád na doraz

Koukni do htop, jestli něco nežere procesor.

oblíbené programy nespustím

S něčím může pomoct Wine, ale pokud potřebuješ software fungující pouze na Windows, tak asi budeš muset použít Windows, překvapivě.

telefon nepřipojím

iPhone jsem nezkoušel, Androidy fungujou přes jmtpfs. Stačilo říct "jmtpfs /mnt/něco" a připojilo se to. Generické dumbphony jsem používal přes blueman-applet + obexfs, infraport chodil, bluetooth byla docela magie.

a to u toho sedím první den

To je asi normální, čekal jsi, že hned budeš mít schopnosti ostříleného admina?

Zálohování, v dnešní době neexistuje funkční řešení jak vytvořit bitovou kopii disku aniž bych musel vypínat PC a načítat nějakou otřesnou CloneZillu která ve finále zálohuje šifrovaný disk 3 hodiny ?

Asi ne, osobně jsem nic takového vlastně nikdy nepotřeboval. Vždycky jsem kopíroval soubory.

Nechápu jak může někdo srovnávat Windows a Linux, jsou to absolutně zcela odlišné věci.

Také to nechápu…

Mám někoho zavolat aby mi to za 5 000 nastavil ?

No mě takhle lidi platí za správu serverů, ale přiznám se, že osobně bych se o BFU domácí desktop komerčně starat nechtěl.

Čeština, otřes, ani ta základní pitomá instalace není celá v češtině

Blbá distribuce, ale jinak jo, spousta věcí lokalizovaná není.

každý anglicky neumí a já už se to v 55 letech učit fakt nebudu

V tom případě se obávám, že správa Linuxu není věc pro tebe. Bez urážky, to je prostě fakt. Většina dokumentace, manuálů a návodů na internetu je prostě anglicky, chybové hlášky, komentáře a výpisy systémových utilit rovněž, a nikdo s tím nic nenadělá.

Je tady opravdu někdo, kdo používá výhradně a pouze Linux na něco jiného než brouzdání po internetu ?

Já, od ledna 2007. Komerčně dělám admina a vývoj embedded elektroniky, do toho studuju matfyz a ve volném čase spolupracuju na různých udělátorech.

zbývá už jenom Apple s HW o hovně za 60 000

Apple mi přijde, že taky šmíruje.

[k3dAR]

A jaké pak potřebuješ vědomosti ve Windows ? Otřepané fráze linuxáků.
predstava ze budu celou zivot pouzivat Linux a pak prijdu poprve na Windows a budu cekat ze za par minut vsechny rozdili pochopim a vsechny problemy vyresim?
znam Linux i Windows desitky let a vim ze oba systemy maji spoustu veci jinak a oba sem se musel ucit, lidi co pouzivaji Windows maji naucene nektere veci co povazuji za samozrejme, ale ucit se pak nejake nove veci s Linuxem nechteji (pritom prejit na Linux by chteli)...

[pavlix]

No nevím. Asi nemá cenu srovnávat různé kategorie uživatelů systémů. Sice používám Linux, na Windows se dostanu jen výjimečně, ale proto, abych řešil uživatelům Windows jejich problémy. Při stejné úrovni znalostí každý na svém systému bych jim asi moc nepomohl, i když stejná úroveň znalostí na Windows a Linuxu je od určité úrovně spíše hypotetická, pokud člověk nedělá v Microsoftu na nějaké hodně cool pozici. Neochotu uživatelů učit se nové věci svým způsobem chápu, ale zase na druhou stranu totální neflexibilita nedělá dobrotu.

[k3dAR]

to nic nemeni na tom, ze s Windows se kazdy uzivatel Windows musel neco naucit, pokud chce prejit na jiny system, nemel by nadavat/odmitat ze se musi neco noveho/jineho naucit, to je cele :)

[Gustav]

Souhlasím, nenadávám, jen brečím :) Rád se něco naučím, ale ne za cenu toho, že budu muset vždy nainstalovat znova celý OS. Čili co a jak mám zazálohovat pro rychlou obnovu ?

[pavlix]

Ta zrovna zálohovat systém pro rychlou obnovu je na Windows jedna z nejzákladnějších věcí, co se člověk naučí, pokud nechce reinstalovat.

[pavlix]

Ale tady, jestli to dobře chápu, jde o nepovedenou instalaci. To je normální situace, když se člověk s něčím učí. Jednou jsem Windows zkoušel instalovat hodněkrát po sobě, než jsem zjistil, že je service pack nekompatibilní s daným hardware.

[Andrej]

Aha! Tak teď už vím přesně, kde je chyba! Přesně tyto výše popsané symptomy jsem už cca desetkrát viděl a pokaždé to byl přesně tentýž problém: překážka mezi židlí a klávesnicí.

Tu překážku je třeba odstranit. Prvním krokem je získání nějakých základních znalostí ohledně UNIXu a Linuxu a druhým, neméně důležitým krokem je pochopení, že totalitní svět Windows, ve kterém je všechno možné (nebo spíš nemožné) jedním způsobem, se zásadně liší od svobodného světa Linuxu, kde pro daný problém existuje spousta různých řešení a spousta různých názorů na ně.

[Andrej]

Je tady opravdu někdo, kdo používá výhradně a pouze Linux na něco jiného než brouzdání po internetu ?

Ano, je. Například já. Od roku 2004 jsem neviděl Windows ani jednou a nikde je nemám nainstalované. Na Linuxu jsem vystudoval, Linux je všude od mé domácí sítě až po obrovské systémy v práci. Brouzdání po Internetu je sice bezva, ale pár her ze Steamu nebo 4k video taky není k zahození. A taky to není problém. Tisknu. Čeština mi všude funguje bez problémů (leč po instalátoru od takového ArchLinuxu bych ji fakt nevyžadoval). Scanuju. Wifím (AP i klient). Přijímám DVB-T… Fakt nevím, co by mi mohlo chybět.

[pavlix]

Ani jsem nezaregistroval tuhle kupu sraček. Ano, hádáme se jako malí kluci, to je snad základní vlastnost internetových diskuzí, kam může každý, kdo má do řiti díru. Většina informací, co tady píšeš je zcela mimo realitu. Existují placené distribuce. Existují distribuce s instalátorem v češtině. Místo šmíčáckého windows šmírácký apple, to si pomůžeš. :)

Jo a s tou šedesátiletou slivkou klidně přijeď. :)

[Jendа]

No, jak to tak čtu, je to složitější než se zdálo

Mně přijde MD RAID (nebo i ten BTRFS) jednodušší než nějaké utility výrobce -- především proto, že máme řadiče od tří různých výrobců, kde každý dodává nekompatibilní sadu různě (ne)kvalitních utilit (některé nepodporují kernel >=3.0, protože tam je natvrdo check na 2.6.něco a zařízení již není podporováno, nakašlete si, některé jsou bastl v Javě, …), zatímco tohle je na každém systému stejné, takže se to stačí naučit jednou.

[alles32]

pic

kam ukladat zalezi na tvoji konfiguraci kompu.

u radice co umi hw raid (cena od cca 6k) zalezi na radici a jeho driveru. muze se jmenovat /dev/cciss a nebo taky /dev/afa https://wiki.debian.org/LinuxRaidForAdmins

pokud's ho sestavil v biosu zakladni desky, tak je to fakeraid a najdes ho najdes /dev/mapper/chipsetName_randomName. https://wiki.archlinux.org/index.php/Installing_with_Fake_RAID

pokud nemam radic, rak spis nez po fakeraidu pouziju soft raidu. umi ho sestavit instalator kazdy vetsi distro (debian, centos, ubuntu). k znovusestaveni staci mdadm ktery najdes na vsech linuxech - raid sesraveny jednim konkretnim radicem nemusi jiny umet dat dohromady. disk se pak jmenuje /dev/mdx https://wiki.archlinux.org/index.php/Software_RAID_and_LVM

[Jendа]

Vykašlat se na pochybné fakeraidy a použít normální MD RAID.

[Andrej]

Vykašlat se na pochybné mdraidy, které nejsou o nic lepší než hardwarové nebo fake raidy, protože neřeší problém silent data corruption, a použít prostě normální Btrfs.

[Jendа]

A viděl už někdo někde silent data corruption? btrfs je pořád nedovařený. Ano, i na posledních kernelech.

[Jooky (inactive)]

Ja som to uz videl vela krat. Dokonca aj na abclinuxu to ludia reportovali ... co konkretne nie je na btrfs dokoncene ? (neratam RAID5/6).

[Jendа]

Ja som to uz videl vela krat. Dokonca aj na abclinuxu to ludia reportovali

Kde? Předposledně se ukázalo, že MD to u RAID1 neumí ani reportovat (počítá mismatch i nad nealokovanými bloky -- stačí tam poslat trim nebo nežurnálovaný zápis a začne se to lišit), posledně se ukázalo, že to byl notebook s USB diskem bez ECC, což je spolehlivost sama.

[Andrej]

Ano, silent data corruption se objevuje v podstatě po každém výpadku napájení a nelze tomu nijak zabránit. To se koneckonců ví už dávno. Tak (ne)fungují současné disky a SSD se svým falešným potvrzováním sync příkazů (jen aby vyhrály benchmarky) a s NCQ. Silent data corruption není nic výjimečného, co by nikdo nikdy neviděl. Ve větších skupinách strojů je to v podstatě každodenní realita — dokud Btrfs nezjedná pořádek.

Nedovařenost Btrfs je FUD. Ext4 je mnohem hůř nedovařený, měl v posledních 5 letech mnohem víc zásadních problémů, včetně ztráty dat jen kvůli softwarové chybě, bez „zavinění“ hardwaru, a přesto se najdou jedinci (ba i velké instituce!) používající Ext4. Nechápu, kde se bere tento nesmyslný dvojí metr.

Jednu hypotézu bych měl: Kdyby se Btrfs jmenoval Ext5, byl by už asi tak 5 let výchozí (ne-li jedinou) volbou ve všech instalátorech. Protože se nejmenuje Ext5, někteří ho zkrátka nedovedou strávit.

[Jendа]

Ano, silent data corruption se objevuje v podstatě po každém výpadku napájení a nelze tomu nijak zabránit.

Ještě štěstí, že už 16 let máme žurnálovací souborový systém…

Disk errors. The wrote a special 2 GB file to more than 3,000 nodes every 2 hours and read it back checking for errors for 5 weeks. They found 500 errors on 100 nodes.

Na tohle mám bohužel málo nodů…

RAID errors. They ran the verify command on 492 RAID systems each week for 4 weeks. The disks are spec’d at a Bit Error Rate of 10^14 read/written. The good news is that the observed BER was only about a 3rd of the spec’d rate.

…ale tohle (chybu každých přečtených 38 TB) prostě nepozoruju. Mám něco jako 30 TB dat a čtu je pro kontrolu každý měsíc a ještě jsem žádnou chybu neviděl.

Nedovařenost Btrfs je FUD.

Není, popsal jsem několik případů, které jsem s ním zažil, a to ho mám jenom na notebooku, 1 serveru a 2 6TB polích.

[Andrej]

Žurnálování obecně nijak neřeší silent data corruption. Ano, může odchytit některé specifické případy, ale obecně problém nijak neřeší, protože žurnály i „perzistentní“ můžou disky zapisovat v libovolném pořadí, klidně i nesprávném z hlediska odolnosti vůči výpadkům, a protože zápis chybných dat může nastat i z jiných důvodů než kvůli výpadku napájení. Co když disk ze své přeuspořádané fronty operací stihne do žurnálu či do stromu inodů zaznamenat úspěšný zápis několika bloků dat, ale bloky samotné už kvůli výpadku napájení nezapíše? Ani tento případ žurnálování samo o sobě neřeší. Zato checksumy ano. (Přesněji řečeno, naprosto zásadně snižují pravděpodobnost, že se na to nepřijde, když už se to stane.) Na filesystému s jednou replikou dat je pak příslušný soubor ztracený, ale s více replikami dat (ať na jednom disku nebo na více discích (RAID)) se data dají celkem deterministicky obnovit a zachránit. Jistě, pokud neselžou 2 související bloky v RAID5 nebo všechny související bloky v RAID1. Pak se situace převádí na případ s jednou replikou dat na jednom disku — ztracený soubor, ale s přesným oznámením, který to je.

S tou nedovařeností nějak nezmiňuješ, jestli třeba vyčištění space cache pomáhá nebo zda a jak jsi otestoval, že všechny disky v těch 6TB polích jsou opravdu v pořádku a že žádný z nich nemá divný problém s throughputem atd. atp. Jasně, mohl jsi narazit na nějaký nový výkonnostní bug v Btrfs, ale bez vyloučení dostatečného počtu dalších možných příčin se to dá těžko přesvědčivě prokázat.

[Jendа]

Co když disk ze své přeuspořádané fronty operací

Pokud nelže o tom, co už zapsal, a co ještě ne (tj. frontu potvrzuje out-of-order, nebo počká a pak potvrdí celou), tak s tímto žurnálovací FS počítá.

[Jendа]

btrfs je pořád nedovařený. Ano, i na posledních kernelech.

Abych jenom prázdně nekecal:

• Furt mi nikdo nebyl schopen vysvětlit, jak je možné, že mount 6TB btrfs svazku trvá minutu. Děje se mi to na dvou rúzných svazcích na dvou úplně různých počítačích, tak to asi nebude nějaký jeden poser.
• Kvůli CoW se strašlivě fragmentují pro sekvenční čtení soubory, ve kterých měním obsah inplace. CoW nejde, jako většina ostatních mount options, vypnout pro subvolume, ale jen pro celý FS, při čemž po jeho vypnutí se většina výhod a funkcí btrfs ztrácí.
• Nejde vypnout autodefrag.
• btrfs (v RAID1) vyrobilo soubor, jehož přečtení způsobí I/O error. Budiž, to se může stát každému, od toho jsou zálohy. Jenže ono to ten error nikam nezaloguje!
• Vývoj je strašně rychlý a dokumentace za ním zaostává, takže tam najdeme eastereggy jako třeba že někdo napsal kompresi, ale ještě nikdo nenapsal dekompresi (budiž), ale na stránce o kompresi není velké tučné varování, o tom je někde úplně jinde nepatrná poznámka.

[Heron]

Furt mi nikdo nebyl schopen vysvětlit, jak je možné, že mount 6TB btrfs svazku trvá minutu. Děje se mi to na dvou rúzných svazcích na dvou úplně různých počítačích, tak to asi nebude nějaký jeden poser.

Nevím, mě mount 12TB svazku (ze kterého se, kromě btrfs rootu, mountuje asi 10 subvolume na různá místa) asi 20s. A to asi jen proto, že to systemd dělá všechno paralelně.

Kvůli CoW se strašlivě fragmentují pro sekvenční čtení soubory, ve kterých měním obsah inplace. CoW nejde, jako většina ostatních mount options, vypnout pro subvolume, ale jen pro celý FS, při čemž po jeho vypnutí se většina výhod a funkcí btrfs ztrácí.

chattr +C na nový prázdný adresář vypne COW pro všechny objekty, které v tom adresáři vzniknou.

Navíc máš možnost ten soubor defragmentovat.

Vývoj je strašně rychlý a dokumentace za ním zaostává, takže tam najdeme eastereggy jako třeba že někdo napsal kompresi, ale ještě nikdo nenapsal dekompresi (budiž), ale na stránce o kompresi není velké tučné varování, o tom je někde úplně jinde nepatrná poznámka.

Jako budiž, ale nedělal bych z toho kovbojku. Když si to nejdřív připojíš jako compress a potom to zase vypneš, tak se sice data neodkomprimují, ale to v zásadě ničemu nevadí. A pokud to vadí, tak ta data jednoduše zkopíruj do místa, kde není komprimace aktivní. Ale nenapadá mě, proč tak hrozně vadí, že nějaké bloky jsou komprimované.

Já mám jeden konkrétní btrfs fs pátým rokem, zkoušel jsem na něm vše možné (výměny devices, komprimace s různými algoritmy), v jednu chvíli měl několik desítek tisíc snapshotů (aktuálně 6 tis.), takže tady jsou soubory dat se všemi možnými profily rozházené všude možně, ale že by to nějak vadilo jsem si nevšiml.

[Heron]

A jen možná drobné OT doplnění:

Díky vlastnostem některých technologií se také snáze odhalují nedostatky jiných. Ano, BTRFS má z principu pomalejší fsync, ale to v zásadě nevadí, protože sync je obecně pomalá operace a většinou se dělá tehdy, kdy je to skutečně nutné.

Takže, ano, debootstrap nového kontenjeru dělám na XFS a potom udělám rsync -a do připravené subvolume, protože takto je to mnohem rychlejší, než když ten debootstrap běží rovnou na btrfs. To ale není chyba btrfs, ale toho, že dpkg volá milionkrát sync na instalaci jednoho balíčku.

Stejně například online backup postgresu odhalil prasárnu v jedné db (ttrss), která ačkoliv má 46MB na disku, dokáže za týden vygenerovat 3GB WAL logů. Ukázalo se, že vývojáře nenapadlo nic lepšího, než volat neustále update table set * (v podsatě) bez where, takže se neustále updatuje celá table a do walu chodí old rows.

Sice je to OT, ale krásně to ukazuje, že vše zlé je k něčemu dobré. Možná i ten soubor, který se náhodně inplace zapisuje není potřeba číst celý sekvenčně.

[Jendа]

Díky vlastnostem některých technologií se také snáze odhalují nedostatky jiných. Ano, BTRFS má z principu pomalejší fsync, ale to v zásadě nevadí, protože sync je obecně pomalá operace a většinou se dělá tehdy, kdy je to skutečně nutné.

Jo, na to už jsem taky přišel, a díky tomu jsem ve své aplikaci opravil zbytečně časté commity sqlite

Debootstrap, resp. dpkg/apt/aptitude, mě taky štvalo, a na Class4 SD kartě (různé Raspberry a podobné destičky) je to úplně vražedné, ale objevil jsem super utilitu eatmydata a udělal jsem si na ni aliasy pro apt-get a debootstrap a fičí to.

[k3dAR]

dik za eatmydata, pisu si do denicku :)

[Jendа]

Jako budiž, ale nedělal bych z toho kovbojku. Když si to nejdřív připojíš jako compress a potom to zase vypneš, tak se sice data neodkomprimují, ale to v zásadě ničemu nevadí.

Já to chápu, a konkrétně tohle mě netrápí. Spíš se bojím, jaké další eastereggy ještě najdu.

Btw. to dlouhé připojování, autodefrag a hlavně ten I/O error bez zápisu do dmesg bych rád opravil, ale nevím, jak.

To dlouhé připojování je jedno na (MD)RAID6 z 6 desktopových 1.5TB disků a jedno na MDRAID5 ze 4 2TB disků, jedno je Core2Quad a jedno Athlon X2.

[j]

Nevim co mountujes, mountuju 4x6TB v R5 a trva to vterinu(no dobre, mozna dve).

To samo neznamena, ze tam nekde neni bug, ale jak bylo receno, nedelal bych z toho tragedii, pouzivat se to da, ma to nejaky ficury ktery muzou bejt zajimavy a proste nejaky "ale", na ktery muze obcas nekdo narazit.

[Andrej]

Tohle je naprosto nefér srovnání, že ano.

Vem v úvahu pouze tu funkcionalitu, kterou poskytuje Ext4 / XFS / JFS / DalšíČastýFS a srovnej, jak ji zvládá Btrfs. Bez nejmenších problémů, řekl bych. Nic nedovařeného tam nevidím.

Jenže Btrfs má spoustu killer features navíc. Konečně opravdu funkční RAID (po všech těch děravých rádoby-abstraktně-rozvrstvených pokusech, které v minulých desetiletích postupně vznikaly), checksumy (killer feature No. 1, řekl bych, hlavně ve spojení s RAIDem) a nakonec i CoW, protože cp --reflink nebo snapshoty celých subvolumes jiný filesystém hned tak neumí. (Leda ZFS.)

Ohledně problémů s výkonem si neodpustím otázku, zda se jedná o nejnovější kernel. Minulý rok se například vyskytla stížnost ohledně výkonu Btrfs pod PostgreSQL (se zbytečně FUDovitým titulkem, ale budiž), na kterou přímo vývojáři zareagovali celkem rychle. Jenže na ABCLinuxu se víc než často objevují nářky, jak někdo zkusil nějaký rádoby-stabilní kernel z roku 2013 (třeba 3.13.něco), který sice možná obsahuje backporty bezpečnostních oprav, ale nemá backporty ladění výkonu filesystémů, a výkon nebyl podle jeho představ.

U toho dlouhého mountu bych se já osobně asi spíš zajímal, co se o tom píše v logu a jestli například systemd (nebo který init systém tam je) nemá problém zařízení odmountovat při vypnutí. Občas se stává, že to po (poměrně krátkém) čase celkem radikálně vzdá a následně se pak při dalším startu mountuje nekonzistentní filesystém, což pochopitelně trvá dlouho. Předpokládám, že space_cache [1] [2] nebo inode_cache jsi už zkoušel…

[Heron]

Ohledně problémů s výkonem si neodpustím otázku, zda se jedná o nejnovější kernel. Minulý rok se například vyskytla stížnost ohledně výkonu Btrfs pod PostgreSQL (se zbytečně FUDovitým titulkem, ale budiž)

Navíc tento článek je poněkud pikantní v tom, že se jedná konkrétně o PostgreSQL, což je db s multigenerační architekturou (takže taky něco na téma cow - při update vznikají kopie řádků) a postgresql musí řešit podobný garbage collecting jako btrfs. Jenže zatímco v PostgreSQL se vacuum řeší už desítky let, tak celé btrfs je staré sotva jednu desítku. Takže pokud si autor stěžuje na pomalý běh btrfs, tak by si měl také uvědomit, jak dlouho to trvalo postgresu, než se dostal na současný stav (a není to ani těch 10 let, kdy autovacuum nebyl ani by default zapnutý a bylo zvykem to řešit ručně).

[Jendа]

Konečně opravdu funkční RAID (po všech těch děravých rádoby-abstraktně-rozvrstvených pokusech, které v minulých desetiletích postupně vznikaly)

Mám tady stroj s rozbitým btrfs RAIDem

# dmesg|tail -n 1
[18195952.626341] systemd-udevd[24293]: starting version 215
# cat /home/xxx/Maildir/.INBOX.Sent/dovecot.index.log.save 
cat: /home/xxx/Maildir/.INBOX.Sent/dovecot.index.log.save: Input/output error
# dmesg|tail -n 1
[18195952.626341] systemd-udevd[24293]: starting version 215
#

a fakt rád bych tu chybu opravil, poraď mi, kde mám začít. Je to 4.1, teď jsem tam nainstaloval 4.5, ráno to budu moct rebootnout (prekérní situace, je to ještě k tomu nejdůležitější server na katedře…).

U toho dlouhého mountu bych se já osobně asi spíš zajímal, co se o tom píše v logu a jestli například systemd (nebo který init systém tam je) nemá problém zařízení odmountovat při vypnutí.

Ne, to není při zapnutí, to je i když to jen tak umountnu a hned zase mountnu. A děje se to pokaždé (=nejsou to cache).

# dmesg -c; date; umount /mnt/backup ; date; mount /mnt/backup/; date; dmesg
Čt dub 28 21:21:32 CEST 2016
Čt dub 28 21:21:41 CEST 2016
Čt dub 28 21:22:39 CEST 2016
[6668590.955310] BTRFS info (device md1): disk space caching is enabled
# dmesg -c; date; umount /mnt/backup ; date; mount /mnt/backup/; date; dmesg
[6668590.955310] BTRFS info (device md1): disk space caching is enabled
Čt dub 28 21:22:56 CEST 2016
Čt dub 28 21:23:08 CEST 2016
Čt dub 28 21:24:07 CEST 2016
[6668677.193648] BTRFS info (device md1): disk space caching is enabled
# 

iotop během toho ukazuje:

 9740 be/4 root        2.92 M/s    0.00 B/s  0.00 % 99.99 % mount /mnt/backup/

takže to nejspíš prostě strašně seekuje po poli…

[Heron]

Jestli ten soubor jde smazat, tak ho smaž. Dovecot si to povytváří znovu. Samozřejmě to neřeší případnou chybu v btrfs, nebo kde vlastně je.

[Jendа]

Soubor jsem obnovil ze zálohy hned jak mě na problém upozornil rsync a funguje to v pořádku. Problém ale vidím v tom, že to nevypíše do dmesg že nemůže přečíst sektor (ani z jednoho disku?) případně že došlo k jiné chybě. Zítra rebootnu do 4.5 a spustím scrub… Tím se to teda asi definitivně „vyléčí“ bez odhalení příčiny…

[Jendа]

Po rebootu do 4.5 se soubor stal čitelným. Poznamenávám, že jde o stroj s ECC a byl kompletně reinstalován (z CentOS 5 :) v září a FS byl vytvořen na 4.1, takže nejde o žádný prehistorický FS. Běží scrub.

[Jendа]

scrub doběhl, nenašel žádné chyby…

[Andrej]

Já bych to bral pozitivně: Být tam Ext4, klidně by celé měsíce servíroval hausnumera (nebo možná jen sekundy — zkrátka do doby, než by kvůli tomu ten Dovecot třeba odletěl) a neřekl by ani půl slova o tom, v čem tkví problém. S Btrfs jsi problém odhalil a zjistil přesně, který soubor je poškozený a co se tedy musí obnovit ze zálohy.

Tohle je přesně klíčová výhoda Btrfs v akci.

Pokud se objeví nějaké nesrovnalosti v metadatech, což jsem v roce 2010 fakt zažil, někdy stojí za úvahu napsat do příslušného mailing listu a zeptat se, jak vývojářům poskytnout (rozumně anonymní) debugovací data, například dump různých důležitých datových struktur a podobně. To ale asi nepřichází v úvahu, když se posere IMAP server a je potřeba ho do <N minut dát do pořádku — tak už to chodí.

Jedno je téměř jisté: Jestli se to stane zase, Btrfs to zase odhalí.

[R]

Btrfs odhalilo co? Subor necitatelny a v logu nic.

[Andrej]

Dokud lidé nepochopí, že žádná data jsou lepší než náhodná poškozená data à la Ext4, bude se silent data corruption na světě dobře dařit.

[Jendа]

Ještě ukázat, že tento error vznikl kvůli silent data corruption (je to RAID1, takže by se musel poškodit na obou discích; stoj jsem od září do včera nerebootoval a je tam UPS).

[Jendа]

je to RAID1, takže by se musel poškodit na obou discích

Což by pak ale nenapsalo

	scrub started at Fri Apr 29 14:11:48 2016 and finished after 10180 seconds
	total bytes scrubbed: 2.76TiB with 0 errors

[lertimir]

Jako člověku neznalému v linuxu bych doporučoval 1. vykopírovat z windowsího(sích) disku(ů) data, třeba někam na externí medium. tím se ti uvolní ruce a můžeš si nainstalovat standardní linuxový raid (jak už bylo zmíněno MD raid. Jde to udělat i jinak, ale problémy a rizika ztráty dat, když přesně nevíč co děláš jsou velké.

[Andrej]

Doporučuji nenechat se zmást prehistorickými nápady typu mdadm, které tu někteří (nejspíš pro zábavu) plácají.

Linux bys měl instalovat na oba disky zároveň. To umožňuje standardní souborový systém Btrfs.

[dustin]

Přestaň už tady hlásat svou jedinou pravdu a mást nově příchozí. mdraid má a bude ještě hodně dlouho mít své opodstatnění a je to standardní způsob sw raidu v linuxu. Btrfs jej jednou možná nahradí, pokud vše půjde dobře.

[Andrej]

Tento^^^ komentář je z roku 2010. Dnes máme rok 2016. Nic víc se k tomu asi dodat nedá.

Kromě toho, není přece žádná jediná pravda. ZFS je taktéž volba hodná 10. let 21. století. Jenže zprovoznit ZFS na Linuxu je těžší než zprovoznit Btrfs, který je rovnou v kernelu.

[AraxoN]

MD RAID je jednoduchý a rokmi preverený. Návody nájdeš všade a keď to "kľakne" poradí Ti každý druhý admin. A keďže výsledkom je blokové zariadenie, môžeš nad ním robiť ďalšie čary, ktoré s Btrfs tak ľahko nespravíš - šifrovanie celého zariadenia, swap oddiel, iný filesystém pre iný druh záťaže, delenie na ďalšie oddiely, boot zo starých grub/lilo, nepotrebnosť initramfs...

[j]

A pravdepodobnost ze to "kľakne" je 100%.

2Gustav: bejvaly casy, kdy to tux umel normalne pripojit (2.6.18 je posledni jadro, ktery to umelo), pak se pani rozhodli, ze je to politicky nekoretkni reseni, a smolik.

SWraid je velmi nebezpecna vec, o ktery najdes kdyz zagooglis miliony dotazu co stim, kdyz ze to podela. A podelat se to umi tak, ze prijdes o data. Neumi to totiz treba poznat, kterej disk mel vypadek - staci kdyz na chvilu usne/ztrati napajeni/... a ses doslova v <>.

Takze pokud chces realne pouzivat klasickej raid, kup si raid HW. Z frcu za par korun. Trebas http://servershop24.de/.

Zmineny btrfs je samo jedna z variant taky, v konfiguraci zrcadlo by to melo byt uz bezproblemovy. Ale zkratka to neni rekneme "provereno casem". Na druhou stranu to nese spoustu vyhod - narozdil od klasickyho raidu nemas problem pridat dalsi disky a proste ti pribude misto.

[dustin]

Neumi to totiz treba poznat, kterej disk mel vypadek - staci kdyz na chvilu usne/ztrati napajeni/... a ses doslova v <>.

Máš linky na konkrétní případy? mdraidy používáme dobrých deset let, spoustu disků odešlo, ale zatím jsem se nesetkal s tím, že by nevěděl, který vypadl. Zrovna včera vypadl jeden disk z jednoho z polí - krátkodobý výpadek. Raid10 to samozřejmě poznal a disk vyhodil. Protože v tomto konkrétním případě byla zapnutá write-intent bitmapa, trvalo opětovné zasynchronizování jenom chvilku. Proto by mě zajímaly konkrétní případy.

Samozřejmě HW raid je něco trochu jiného, ale musí jít s kartou (nebo aspoň podobným modelem), což může být někdy starost při přechodu na jiný server. Souhlasím, že použitý (ale i nadále zcela spolehlivý) HW raid je dnes levná cesta.

[j]

Urcite dohledas, sam sem to svyho casu zkousel. Nejvetsi prusery obecne nastanou, kdyz ten disk, co to vyhodilo, zkusis pridat zpet, bez toho, abys ho nejdriv smaznul. Povedlo se mi dokonce docilit toho, ze cast zapisu v zrcadle sla na jeden disk a cast na druhej a vysledek byl dle ocekavani ... samo takova klasika jako ze tomu seberes napajeni, jenze jeden z tech disku to zapsat jeste stihne a druhej ne. Pak mas pole, ktery se tvari zcela koser, ale na kazdym disku mas neco jinyho. Proste takovy ty klasicky problemy vznikajici v SOHO a lowcost.

Tudiz u zcela libovolnyho SW reseni to chce minimalne UPSku (a nebo dobrou zalohu).

Jinak se po netu povalujou i veci na tema ze to z pole vyhodilo zdravej disk, a nechalo to v nem ten chorej, coz specielne u R5 je radost k popukani.

[Heron]

Taky jsem zažil hw diskové pole, které, při pokusu o přidání nového disku (jako náhradu za vadný) jej tam prostě přidalo (bez synchronizace) a začalo z něj normálně číst a zapisovat. FS z toho byl pochopitelně velmi happy a odporoučel se.

Zkrátka bez chytrejch úložišť to nejde.

[R]

Najvacsia sracka, co som kedy videl, je Adaptec ASR-2120S. Vypadok jedneho disku v RAID1 dokaze poskodit data - poskodil sa nejaky adresar vo filesysteme. Alebo aj rozbit cely RAID (druhy pripad) - lahlo to a uz nenabootovalo. Data som zachranil cez dd skopirovanim dobreho disku (cez iny radic) s nejakym offsetom (na zaciatku su metadata), pole sa muselo vytvorit nove. Dokonca aj povodny disk ozil po sg_format (predtym ukazoval nulovu kapacitu).

[pet I.]

SWraid je velmi nebezpecna vec, ...

když do toho hrabe lama. Za cca 20 let co to používáme, a to i u zákazníků, původně RAID5, nyní RAID1, jsme o data přišli jen jednou a to jen proto, že zákazník nechal umřít napřed jen jeden disk a přes několik upozornění že by s tím měl něco dělat pak za půl roku ještě i druhý .

bejvaly casy, kdy to tux umel normalne pripojit (2.6.18 je posledni jadro, ktery to umelo)

Mno, nevím jak tux, ale Linux kernel umí SW raid stále. Jen nesmí být závada mezi židlí a myší.

pokud chces realne pouzivat klasickej raid, kup si raid HW

Ano, například nejnovější "HW RAID" řadiče od HP už provozují také SW RAID, jen se to snaží maskovat do driveru.

A pravdepodobnost ze to "kľakne" je 100%.

To vždy, nic nevydrží věčně, aní SW ani HW RAID

[j]

Jasne, a proto kernel vs dmraid hlasa, ze (napriklad) modul raid45 neexistuje, zejo ... ze si neumis poridit HW radic je tvuj problem.

[Jendа]

SWraid je velmi nebezpecna vec, o ktery najdes kdyz zagooglis miliony dotazu co stim, kdyz ze to podela.

Linux je velmi nebezpecna vec, o ktery najdes kdyz zagooglis miliony dotazu co stim, kdyz ze to podela.

Neumi to totiz treba poznat, kterej disk mel vypadek - staci kdyz na chvilu usne/ztrati napajeni/... a ses doslova v <>.

Jo, samozřejmě, asi mám celý život halucinace.

[Andrej]

SWraid je velmi nebezpecna vec, o ktery najdes kdyz zagooglis miliony dotazu co stim, kdyz ze to podela. A podelat se to umi tak, ze prijdes o data. Neumi to totiz treba poznat, kterej disk mel vypadek - staci kdyz na chvilu usne/ztrati napajeni/... a ses doslova v <>.

Přesně tak. Každý výpadek, který nevede k okamžitému odpojení celého disku, je zdrojem silent data corruption, která se během let postupně kumuluje, až se celé RAID1 pole změní v ruskou ruletu.

A právě před takovými případy Btrfs chrání. Btrfs i ZFS poznají, který disk měl výpadek, protože příslušný disk pro daný RAID blok vrací nesmysly. Filesystém s vestavěnými checksumy to snadno rozpozná. V případě RAID5 pak může data opravit pomocí paritního bloku (případně opravit samotný paritní blok, jehož poškození rovněž pozná) a v případě RAID1 ihned zjistí, kde mu prokládané čtení vrátilo nesmysl a který blok je třeba načíst, ověřit a opravit podle jiné repliky.

Tímto způsobem Btrfs a ZFS snižují pravděpodobnost silent data corruption o několik desítek desítkových řádů, velmi hluboko pod úroveň hardwarového RAIDu s baterií — ten totiž neodolá vadným diskům či kabelům, zatímco Btrfs a ZFS do značné míry odolají.

[Aleš Kapica]

HW raid není ve své podstatně zase nic jiného než softwarový raid na úrovni řadiče. Rozdíl je pouze v tom, že běží nezávisle na systému co je nad ním, ale to je asi tak vše. Jinak sebou nese stejné nedostatky jako md raid. Je-li bez baterky tak je jeho použití snad možná ještě víc riskantní.

[Jendа]

Jinak sebou nese stejné nedostatky jako md raid.

A některé další. Viděl jsem proprietární management tooly, kde se výrobce vykašlal na podporu nových systémů. Viděl jsem pole, které mělo omezení na 2^32 sektorů. Snad nikdy to neumožňuje dát tam různě velké disky a zpřístupnit jejich zbylou kapacitu. Atd.

[Jendа]

Přesně tak. Každý výpadek, který nevede k okamžitému odpojení celého disku, je zdrojem silent data corruption, která se během let postupně kumuluje, až se celé RAID1 pole změní v ruskou ruletu.

Já vídám dočasné výpadky, kdy disk vrátí dočasný error (je to vidět v dmesg a většinou i smartu) a realokuje sektor, a MD RAID to při přístím checku přepíše a je to bez problému. (tyhle věci monitoruju a když je toho víc, tak ten disk radši vyměním preventivně, ale 1-2 chyby občas mívám a v pohodě) Navíc pro jistotu každý měsíc dělám check/scrub.

[Andrej]

Ano, pokud disk ohlásí konkrétní chybu, věřím, že se s tím mdraid i dmraid umí vyrovnat. Silent data corruption ovšem nastává v případech, kdy disk neohlásí žádnou chybu (například proto, že někdo vytáhl vidlici ze zásuvky, všechno běží „na kondenzátory“ a problémy už není jak detekovat a není je komu hlásit, nebo kvůli závadě na disku či kabelu — smutných SATA příkladů se dá najít hned několik).

[Jendа]

Pokud nevěříš CRC v SATA komunikaci, nejspíš nebudeš věřit ani ECC v pamětech a pak máš problém mnohem větší než občasný flipnutý bit na disku.

[Andrej]

Nejde o to, čemu věřím. Jde o to, co může selhat a s jakou pravděpodobností. A taky jde o to, že selhání nemusí být zrovna v CRC. SATA komunikace přece není jediný mechanismus, kterým data projdou na cestě z RAM na disk. Závada může být kdekoliv po cestě, případně v (proprietární) elektronice disku. Často taky přijde problém zvenčí, v podobě přerušeného napájení nebo elektromagnetické interference.

Nikdy jsem sám osobně nezažil, že bych musel měnit SATA kabel (ať už z jakéhokoliv důvodu). Nicméně kapitola Data Path Corruption v tomto dokumentu je zajímavá. Jinde na webu se taky válí měření a pozorování na toto téma.

(To jen k tématu, zda silent data corruption opravdu existuje. Jak pravděpodobná je na jednom dobře udržovaném domácím stroji, to je samozřejmě jiná otázka.)

[Andrej]

MD RAID je jednoduchý a rokmi preverený.

Ano, je léty prověřené, že silent data corruption je vskutku velký problém a že {md,dm}raid ani hardwarový raid před ní nijak nechrání. Btrfs ano.

Návody nájdeš všade a keď to "kľakne" poradí Ti každý druhý admin.

No, když to klekne, tak to prostě klekne. Návodů je (možná stále ještě) víc než pro Btrfs, nicméně systém, který chce někdo nainstalovat a pár let používat, není nutné volit podle momentální dostupnosti té či oné dokumentace. Spíš je asi lepší zjistit, kterým směrem jde vývoj.

šifrovanie celého zariadenia

Ano, pravda, tohle Btrfs nemá. Při běžném prokládaném čtení by to vyšlo nastejno, co se zátěže procesoru týká, nicméně, zápis by vyžadoval šifrování dat pro každý z obou disků zvlášť (předpokládám-li na každém disku jeden LUKS oddíl a Btrfs přes oba LUKS oddíly).

Nicméně u současných procesorů s AES-NI (tedy v podstatě u čehokoliv novějšího než Westmere, jestli se nepletu) bych si troufal tvrdit, že je to skoro úplně jedno. S hardwarovou akcelerací má procesor throughput většinou kolem 2 GB/s, co se šifrování týká, takže nějaké dva disky budou svým celkovým throughputem velmi hluboko pod možnostmi (jednoho!) procesoru.

swap oddiel,

Nic proti swap oddílu. Linux má přirozeně vestavěný RAID0 (když se zapne víc swap oddílů), případně může existovat RAID1 swap oddíl paralelně s Btrfs. (Nejsnazší volbou pro takový swap je asi LVM a dmraid místo zastaralého mdraidu.)

delenie na ďalšie oddiely

Což způsobí, že prostor {je,není} k dispozici tam, kde {není,je} potřeba. Dělení na oddíly by se měl člověk za každou cenu vyhnout. Je-li dělení nutné (například chci-li za každou cenu nešifrovaný /boot a chci-li swap pro uspání na disk), LVM je vždy jednodušší volba.

boot zo starých grub/lilo

To někdo chce / potřebuje?

nepotrebnosť initramfs

Moc si neumím představit dnešní distro se systemd, které by nemělo initramfs. Míval jsem takovou konfiguraci na ArchLinuxu s vlastním kernelem, ale to bylo možné asi tak do roku 2007. Má-li spolehlivě fungovat například šifrovaný root filesystém nebo jakákoliv netriviální konfigurace root filesystému (v mém případě například Btrfs na LVM na LUKS na LVM na GPT), je initramfs v podstatě nezbytný.

[R]

V robote mam jeden server s Gentoo - je tam LILO a nie je tam initramfs.

[Jendа]

To bude nějaká legacy instalace, která už běží na nějakém starém FS a nový tam nikdo dávat nebude. Andrej asi mluvil o nově instalovaných systémech. Že nebudu hned migrovat všechny existující servery na btrfs je asi jasné.

[AraxoN]

Pred týždňom som nasadzoval nový NFS server, Gentoo linux, kernel-4.4, bez systemd, bez initramfs a s grub-0.97. Možno takých use-case veľa nie je, ale to neznamená, že vôbec neexistujú.

Pre mňa riešenia typu "všetko v jednom" (btrfs, systemd) odstraňujú vrstvy izolácie problému. Keď mám RAID, na ňom LUKS, a na ňom FS, tak viem čo ktorá vrstva má robiť, ako ju otestovať a ako opraviť keby prestala fungovať. Keď je to všetko v jednom monolitickom čude, tak zostáva len sa prežehnať a dúfať, že to nejako pôjde.

[R]

Ano, je to stara instalacia. Server som zdedil, naucil som sa na nom pouzivat Gentoo a udrzujem ho. Je tam ext3, reiserfs a xfs, vsetko nad mdraid.

Je to obycajny stary desktop, povodne Celeron 433, potom som prehodil disky do ineho PC (Celeron 1,3 GHz), pretoze odisiel jeden IDE disk a tie sa uz nedaju zohnat. SATA radic v povodnej doske odmietal fungovat, v "novej" funguje - je tam teraz RAID1 nad IDE a SATA diskom.

[ewew]

Ja zase doporučujem prestať vytvárať zbytočne veľke data. Tým by pár problémov odpadlo.

[Andrej]

Přesně tak. Zrovna jsem se chystal navrhnout děrné štítky jako nejlepší alternativu.