Dotaz: Fedora 33, kernel panic, btrfs bad tree block

[xhombre]

Ahoj,

mam nainstalovanou Fedoru 33, nova instalace takze s Btrfs.

Pri bootu skoncim na Switch Root.

S hlaskou

BTRFS error (device sda2): bad tree block start, want 1975959552 have 0

Pokud nabootuju Mint z usb, tak /dev/sda2 normalne mountnu.

pokud spustim btrfs check /dev/sda2

tak dostanu:

Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: b81d6eec-3b78-42f7-a4c2-7b9c325a729d
[1/7] checking root items
checksum verify failed on 2067169280 found 00000074 wanted FFFFFF90
checksum verify failed on 2067169280 found 00000074 wanted FFFFFF90
Csum didn't match
ERROR: failed to repair root items: Input/output error

Pri btrfs check --init-csum-tree /dev/sda2

dostanu

Creating a new CRC tree
WARNING:

	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 can successfully repair all types of filesystem corruption. Eg.
	some software or hardware bugs can fatally damage a volume.
	The operation will start in 10 seconds.
	Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: b81d6eec-3b78-42f7-a4c2-7b9c325a729d
Reinitialize checksum tree
checksum verify failed on 2067169280 found 00000074 wanted FFFFFF90
checksum verify failed on 2067169280 found 00000074 wanted FFFFFF90
Csum didn't match
ERROR: checksum tree refilling failed: -5

Nejak netusim co s tim. Pokud by nekdo dokazal poradit byl bych mu vdecny.

Odpovědi

[MM]

Ahoj, SMART hodnoty disku jsou OK? Neukazuje konec partitiony sda2 za roh? DMESG po chybě Input/output error něco vypisuje?

[xhombre]

Ahoj, dle SMARTu je vse ok.

Dmesg z beziciho Live Mintu nic zvlastniho neukazuje.

Po dmesg | grep -i btrfs dostanu:

[    3.764468] Btrfs loaded, crc32c=crc32c-intel
[    3.767260] BTRFS: device label fedora_localhost-live devid 1 transid 72777 /dev/sda2
[    3.767915] BTRFS info (device sda2): disk space caching is enabled
[    3.767917] BTRFS info (device sda2): has skinny extents
[    3.826878] BTRFS info (device sda2): enabling ssd optimizations
[56432.132608] BTRFS info (device sda2): disk space caching is enabled
[56432.132612] BTRFS info (device sda2): has skinny extents
[56432.211373] BTRFS info (device sda2): enabling ssd optimizations

To mi pripada v pohode

na primountovanem sda2 /var/log/dmesg nemam.

[jetel]

spis bych se mrknul na dmesg | grep sda2 , jestli neni problem s diskem, nejlepe jak to vyhodi ten ERROR: failed to repair root items: Input/output error

[LarryL]

dle SMARTu je vse ok

A zkoušels SMART long test nebo jsi jen zkontroloval hodnoty SMARTu?

[xhombre]

Jen jsem zkontroloval hodnoty ve smartu

[LarryL]

HDD může odcházet a hodnoty ve SMARTu mohou vypadat pořád dobře. Co je to za HDD/SDD? Jak je starý?

[Xhombre]

Je to ssd od Samsungu, prakticky nové. Natočeno podle smartu má cca 20dni. Ale jak jsem odpovídal Jendovi vypadá to na problém s ramkama.

[xhombre]

tak po btrfs check /dev/sda2

v dmesg nic noveho, defacto ten grep najde s sda2 i s btrfs to same.

[trubicoid2]

jaký jádro má ten Mint a jaký Fedora? Není v Mintu novější?

[xhombre]

Mint 5.4.0 Fedora 5.10.8

Fedora ma novejsi

[LarryL]

Myslím, že na kontrolu poškozeného BTRFS se jako první používá btrfs scrub. Jako další se uvádí např. mount -o recovery,ro a btrfs restore

Více na https://btrfs.wiki.kernel.org/index.php/Btrfsck

[Jendа]

vykopírovat data

scrub (jenom pro info, pravděpodobně to nepomůže)

vytvořit nový čistý FS

nakopírovat data zpět

otestovat RAM

[xhombre]

Tak tomu jsem se chtel vyhnout, to znamena celou Fedoru preinstalovat, ale jako posledni moznost s tim pocitam.

Jaka je moznost, ze pri tom scrubu prijdu o data?

[Jendа]

to znamena celou Fedoru preinstalovat

Proč? Je ten FS úplně nečitelný (kdyby se nepodařilo přečíst pár souborů, které jsou z balíčků, tak je snadno donahraješ) a nemáš rozumnou zálohu?

Jaka je moznost, ze pri tom scrubu prijdu o data?

Snad žádná, ale u btrfs nikdy nevíš, takže bych to možná pustil na readonly device, pokud to scrub dokáže (jak si pořídit readonly device nevím, napadá mě buď readonly NBD export nebo to namapovat do virtuálu).

[xhombre]

Fedora ted pouziva jako vychozi fs prave btrfs, takze na tom disku je nainstalovana. Resp. na sda2 je root a home a sda1 je ext4 s grubem, efi atd.

[Jendа]

A?

[LarryL]

Jaka je moznost, ze pri tom scrubu prijdu o data?

Podle mě stejná jako při příkazech, které jsi už použil . Je to opravdu jen ke zkontrolování filesystému: https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub

[xhombre]

Tak jsem se konecne zase dostal k tomu resit notebook. Spustil jsem MemTest86+ z usb a ten se po par procentech sekne, pokud spustim memtester z beziciho liveusb tak take vraci chybu. Takze problem bude v pametech.

Az se dostanu domu tak zkusim otestovat jednotlive moduly, pripadne je vymenit a pak se uvidi. V kazdem pripade dekuji za rady nejen tobe, ale i ostatnim.

[LarryL]

Ze začátku to vypadalo na diskuzi na téma "jaký je ten btrfs šmejd", ale možná, že z toho btrfs nakonec vyjde jako suprovní fs, který dokáže odhalit i vadné RAMky. Další argument pro Andreje při přesvědčování, proč používat btrfs.

[alkoholik]

Pritom je to argument pro pouzivani ECC.

[LarryL]

Notebook s ECC je rarita. Ani Macbooky Pro nemají ECC. Nabídku ntb s ECC neovlivníme, ale to jaký budeš mít FS ovlivníš.

[Petr Fiedler]

Andrej napsal:

(Mimochodem, jakkoliv je například Btrfs nebo ZFS dnes také nezbytnost, fungování ECC nedovedou ani moderní filesystémy plně nahradit, protože k poškození dat může dojít v době mezi výpočtem checksumu a zápisem špinavých bloků na disk (v kterémžto případě si toho poškození lze aspoň později všimnout) nebo před výpočtem checksumu (a pak to bude opravdu silent). ECC takové případy většinou dokáže detekovat a/nebo opravit.)

Za mě je Btrfs určitě super. Rád bych na něj přešel, ale nejsem schopen nainstalovat Mint nad LUKS a Btrfs s neodděleným /boot. Zkoušel jsem všechno možné i nemožné, ale nedaří se mi to. Asi (velmi nerad) oželím LUKS na na ten nový desktop dám Btrfs + Mint + ECC RAM. Tohle vlákno mě v Btrfs a ECC RAM utvrdilo. 2666 MHz myslím stačí, když nehraju.

[LarryL]

když nehraju.

Já si občas zahraju a když se dívám na test různých frekvencí RAM při hraní, tak u prvních dvou her je pokles FPS 5-10% (2800Mhz vs 3800Mhz). Když k tomu přičteš, že se uvádí že ECC sníží výkon ještě o další 2%, tak pro ECC RAM nejsem tak utvrzený jako pro BTRFS.

[Petr Fiedler]

Jaký FS používáš ty?

[LarryL]

Teď starou klasiku: ext4 ...ale jsem rozhodnutý přejít na btrfs. Zřejmě k tomu dojde jak budu upgradovat SSD/HDD. S tím spojím i přechod na jiné distro.

[Petr Fiedler]

Tak to jsme na tom skoro stejně. Taky přecházím na Btrfs při upgradu. Jen distro neměním, protože Mint mi velmi vyhovuje. A budeš šifrovat (LUKS)?

[Petr Fiedler]

... taky z ext4. :)

[LarryL]

A budeš šifrovat (LUKS)?

Ano. Pokud přejdu na Fedoru 33, tak stačí jen zatrhnout políčko "šifrovat disk" při instalaci. Ve výchozím nastavení se nešifruje oddíl /boot, ale v dalších verzích Fedory chtějí by default šifrovat i ten.

[Petr Fiedler]

Že bych zkusil Fedoru? Kouknu se na ní. Díky za info.

[k3dAR]

predpokladam ze to pridaji i v novem-pripravovanem Ubuntu instalatoru, bug o nesifrovani /boot (a zaroven ze volba LUKS maze celej disk a neumoznuje "instalace vedle stavajiciho systemu na disku") je tady teda ne ze by se tam neco zazivneho delo (prevazne je tam nejakej pripad co se snazi obhajovat ze nesifrovanej /boot nicemu a nikomu nemuze vadit , ale kdyz uz pripravujou novej instalator tak snad neudelajou znovu tu blbost aby /boot se pri LUKS oddeloval nesifrovane atd...

jinak v tejdnu bych se uz mel dostat k te uprave luksuntu, resp. doladeni ve virtualu aby slo nainstalovat *buntu/Mint na LUKS vcetne /boot (neoddeleneho), bez LVM a s BTRFS...

[LarryL]

(prevazne je tam nejakej pripad co se snazi obhajovat ze nesifrovanej /boot nicemu a nikomu nemuze vadit , ale kdyz uz pripravujou novej instalator tak snad neudelajou znovu tu blbost aby /boot se pri LUKS oddeloval nesifrovane atd...

Tady je celkem dlouhý článek o Fedoře 33 a Btrfs a mj. v kroku 5, který popisuje jak zašifrovat i /boot píše, že on raději nešifrovaný /boot, aby mohl použít Yubikey:

I actually like to use a Yubikey as a second factor to unlock my luks partition, for this I need an unencrypted /boot partition (see my Things to do after install Fedora 33), so I usually skip this step.

[k3dAR]

tak v tom pripade to asi ma vyznam, ale u toho bugu nesifrovanej boot "obhajoval" tim ze sifrovani nema branit kompromitaci systemu, ale nevytazeni osobnich dat pri ukradeni a tedy kdyz v /boot osobni data nejsou je zbytecne ho sifrovat

[Zoufalec]

MEMTEST explained (linux kernel):

Starting from version 2.6.26 Linux Kernel has an amazing but little known feature - MEMTEST. Let's explore what is it and what it is good for. [...]

[xhombre]

Chtěl bych všem poděkovat za rady a zároveň se omluvit, že jsem se delší dobu neozval.

Nakonec jsem provedl kontrolu pamětí, každého modulu zvlášť a zároveň jsem je i prohazoval ve slotech. Na nic jsem nepřišel všechny testy proběhli v pořádku. Nakonec fungovali i oba najednou. Takže trochu záhada.

Celý system jsem přeinstaloval a zatím vše funguje.

to Jenda: Nakonec jsem pochopil jak jsi to myslel s tím zazálohovat a udělat nový filesystem, když je člověk utahaný občas mu to uplně nemyslí. Pro přeinstalaci jsem se rozhodl kvůli nedostatku místa na kompletní zálohu.

Ještě jednou děkuji všem za jejich čas a rady.

[Josef Kufner]

Ještě si zkontroluj disk, zda tam není nějaký vadný blok. Nabootuj live CD, spusť badblocks v nedestruktivním zapisujícím režimu (přečte data, potrápí blok, vrátí data). Možná pár vadných bloků se najde, možná disk realokuje nové z rezervy a bude se tvářit, že nic. Možná už to udělal, ale pár jich tam možná ještě bude.

[k3dAR]

priznam se ze si nejsem jistej, ale "sudo smart -t long /dev/sdX" a sledovat prubeh/vysledek pres "sudo smartctl -l selftest /dev/sdX" by melo odhalit vadne snad take a pokud ano, tak rychleji protoze to ridi primo FW disku :)

[k3dAR]

by melo odhalit vadne snad take

mysleno totozne vadne jako by nasel badblock, tzn. nevim zda badblock neni "zakernejsi" na zjistovani vadnejch a nedokaze jich odhlalit vice...

[Josef Kufner]

Já bych tomu moc nevěřil. Badblocks udělá to samé jako následně provozovaný filesystém, takže víš, co testuješ.

[k3dAR]

prave, teoreticky by vysledek mel byt ten samej, ale nemam "dukaz", neda se to proverit, protoze kdyz projedu smart long test a pak by badblock nasel neco vice (a obracene), tak nevim jestli to vice by nenasel i znovu pustenej long test, tim ze vadne "rostou rychle", proto sem to i nadhodil, jestli se nenajde nekdo kdo by mel k tomu nejaka fakta :)

[Josef Kufner]

Je to velmi prosté. Testování je vždy proti rozhranní. Badblocks používá to samé rozhranní jako filesystém. SMART test používá interní kdo ví co. Jsou tam jiné možnosti chyb a chování, takže dává smysl ten disk zkusit zatížit tím způsobem, kterým bude používán. Teoreticky by měly projít oba, nebo ani jeden, ale prakticky víme, jak na tom software je.

[xhombre]

Tak prakticky prosli oba dva bez chyb.

[Josef Kufner]

V tom případě gratuluji.

[xhombre]

Tak děkuji. Akorát, že tedy vůbec netuším, co se vlastně stalo. Ale budu Fedoře a Btrfs ještě chvíli věřit. Jen s těmi nástroji na opravu je to bída.

[Josef Kufner]

Pravděpodobně jsi narazil na vadný blok, který disk potichu realokoval, nebo na nějakou náhodnou chybu. BTRFS je takové citlivější a všímavější. Pokud má druhý disk s kopií (RAID1), tak si to opraví, ale na jednom disku to občas nedopadne dobře. Problém BTRFS je, že s obtížnými situacemi se nevypořádává moc dobře. Nemá nástroje na opravu a neumí (alespoň částečně) fungovat v porouchaném stavu. Hloupější filesystémy v tomto jsou lepší, neboť prostě jedou, dokud to alespoň trochu jde. Na druhou stranu, občas to stojí nějaká ta data.

[xhombre]

Tak SMART hlásí Reallocated sector count 0 sectors. Tak snad se tomu dá věřit. Beru to tak, že se prostě sešli spatné okolnosti. Záloha byla, naštěstí nebyla potřeba, takže vše ok.

[Andrej]

Ale budu Fedoře a Btrfs ještě chvíli věřit.

Z tohoto^^^ přímo čiší nepochopení situace. „Kandidát na nedůvěru“ v tomto případě není Btrfs, nýbrž ten disk, na kterém Btrfs je.

Skvělé početní k tématu je tohle vlákno. Pravda, je dlouhé, ale stojí za to. Uživatel tam viní Btrfs z kdečeho. („Why is Btrfs so unstable?”) Jenže pak najednou přijde otázka roku:

…is the drive that this file system is on the same drive as in this reported thread?

A ejhle, ano, je to tentýž disk, který už předtím zničil DM Thin Pool a „dokázal“ pak — překvapení! — poškodit i Btrfs.

Jenže uživatel měl dojem, že s Ext4 přece všechno „fungovalo“. (A že na vině musí nutně být software, nikoliv jeho disk.) Inu, pokud někdo pod pojmem „fungovat“ rozumí „potichu ztrácet data a nic nehlásit“ (jako Ext4), to je potom těžké.

Masové nasazení Btrfs na běžném uživatelském hardwaru, které konečně přichází (se zbytečným 10-letým zpožděním), jistě odhalí spoustu zařízení, která nefungují, jak mají.

Chvíli to bude nepříjemné, ale z dlouhodobého hlediska jde o výrazný pokrok ve spolehlivosti domácích úložišť dat.

[Aleš Kapica]

Marnost nad marnost.

[xhombre]

Tak disk by měl být ok, ale byl tu i ten problém s memtestem, který po šachování s ramkama zmizel, takže bych to viděl na nějakou souhru okolností. Notebook je X201i, tedy žádný mladík, už má asi taky nárok zazlobit.

Osobně si nemyslím, že je BTRFS špatný filesystem, to bych ho ani nezkoušel.

Takže bych výrok o důvěře upravil: "Ještě chvilku tomu notebooku budu věřit. A pořádně zálohovat "

[k3dAR]

[...]Masové nasazení Btrfs na běžném uživatelském hardwaru, které konečně přichází (se zbytečným 10-letým zpožděním)[...]

hele a neni 10let zpozdeni malo? nemel se BTRFS naszovat uz v minulem tisicileti? btw: na wikipedii ctu:

Stabilní: dosud neuvedeno
Nestabilní: v3.4.3, květen 2012 (Linux 2.6.29)
V roce 2014 byl uvolněn v produkční kvalitě.

+ si vybavuju v prubehu par let zpatky na ruzne novinky v BTRFS bez kterejch by to nasazoval produkcne jen masochista

takze se muzem "bavit" o tom ze BTRFS doba k masovejsimu nasazeni dosplela "ted", ok, ale psat ze pred 10lety je zaslepismus ci fanatismus

[lertimir]

Ale zase kecáš. Souhlasím s Andrejem. To že používáš distra která nemají btrfs rády je přesně to, proč je zavedení o 10 let pozadu. openSUSE 11.3 (15.7.2010) umožňuje zvolit jako root filesystem btrfs - kernel 2.6.34, 11.4 (10.3.11) umožňuje zahrnout i snapper a provozovat na btrfs snapshosty - kernel 2.6.37, openSUSE 12.1 (16.11.2011) ho má jako default a má plně integrovaný snapper na rollback po instalacích nebo bo pravidelných snapshostech. A tady se můžeš podívat na video s té doby a Grega K-H.

Tebou uváděné jádro 2.6.29 je ale březen 2009 tedy ano před 12 lety btrfs stabilní nebylo, před 9 ano.

Oracle zahrnul btrfs do svého UEK v roce 2012 a stejně tak SUSE v roce 2012 do SLES 11 SP2 Od SLES 12 v roce 2015 je default. Takže podle tebe jak Oracle tak komerční Suse jsou masochisti.

[k3dAR]

mozna "zase rejpu", ale nekecam Wiki muzes aktualizovat...
ad ty novinky rok ci par let zpet, vybavuju si nejakou moznost opravy, moznost zrcadleni disku a ne jen nahodilejch bloku, pak veci co si uz nepamatuju coz chapu ze neberes jako argument, ale ja to nevedu argument war, jen sem si rejpnul jinak raid5/raid6 uz btrfs podporuje oficialne do produkce? k tem rpm distram se vyjadrovat nebudu, protoze sem je nikdy nemusel a tak nevim co kdy a proc delali

[lertimir]

Jenže to zatím předkládáš jako: Jedna paní povídala. Wiki sice můžu aktualizovat, ale nemusím. Ale na druhou stranu to že něco je napsané ve wikipedii neberu jako písmo svaté, ale ověřuji si informace, když už něco tvrdím, a odzdrojuji to. A jasně pokud kdokoliv chce kopnout do btrfs tak mluví o RAID5/6, ale klidně můžeš jet btrfs nad mdraid 5/6 a dostaneš vyšší jistotu nad daty než pro ext4.

No a to je právně rozdíl, já mám téměř všechno na rpm a v poslední době Arch. Debian a odvozeniny nemám skoro nikde.

Jak říká klasik. Je to marné, marné a marné.

[Petr Fiedler]

Tím klasikem byl král Šalomoun. "Je to marnost", nebo "také toto je marnost", nebo "je to marnost nad marnost" jsou jeho výroky z knihy Kazatel. Mimo jiné to znamená i to, že je to pomíjivé. Z tohoto úhlu pohledu je marnost i Btrfs (které chci místo ext4 časem nasadit).

[k3dAR]

nikoliv, predlozil sem to jasne zpusobem "na wikipedii ctu:", nerikam ze na wiki je vzdy pravda, prave proto sem te "vyzval" abys to upravil, pokud tam je nepravda aby to "nematlo" dalsi navstevniky te page... protoze logicky kdyz nekdo hleda o BTRFS info, Wiki je nejspis prvni co uvidi a co logicky rozklikne, preci ne kazdej bude stodovat mailinglisty, changelogy apod...

neni to "chci si kopnout" je to racionalni otazka, takze z tve "urazene" odpovedi chapu, ze RAID5/6 NEni v BTRFS povazovano k produkcnimu nasazeni, ok...

[Andrej]

Nevím, jak je to s produkčním nasazením, a ani nevím, co to vlastně je, ale pokud jde o konzumační nasazení (což je mi blízké, protože chlastám atd.), tak Btrfs RAID 5/6 mi slouží od roku 2016 k naprosté spokojenosti.

Tuhle mi odešly v RAID5 3 disky (naštěstí ne najednou) a pole to ustálo.

Pak jsem si usmyslel, že disky Mořskábrána typu SMR jsou naprostý odpad, se kterým už nechci nikdy nic mít, a nahradil jsem je za (menší!) SSD. Pro Btrfs žádný problém.

Upřostřed celého nahrazování jsem si řekl, že těch SSD chci vlastně 8 místo 6. No co, pro Btrfs to nebyl žádný problém.

Jo, bylo tam nějaké tření, ale nic zásadního.

[k3dAR]

"production ready" je pokud vim termin pouzivanej bezne na oznaceni neceho vhodneho k nasazeni do produkce, tedy natolik stabilniho ze se na to lze spolehnout a i kdyz me nejdriv potesila tva prakticka zkusenost s raid5/6, tak koukam ze Wiki (tedy nikoliv Wikipedie, ale na kernel.org venovana btrfs) ma u raid5/6 zmineno: pro "Scrub + RAID56" u Stability + Performance = "mostly OK" a na to bylo zmeneno pri jadru 4.12 tedy pred 3lety a dale je tam zmineno ze aktualne u RAID5/6 muze byt problem s "write hole" coz jestli dobre chapu znamena, ze pri ukladani stejnych dat na 2 disky, se muze stat ze na jeden se nedoulozi, ale pritom checkum bude spravne a v pripade poruchy disku na ktery se to ulozilo dobre, se tado data ztrati, resp. nepozna se ze ta 1 kopie neexistuje, to nezni asi moc "production ready"

takze u zakaznika kde mam RAID6 nasazeni ani teoreticky nehrozi, nicmene pro nasazeni me kdy by slo bud o 1 disk, nebo raid1 s 2 disky je to samozrejme irelevantni, nicmene jeste s 3 pokusem s btrfs asi stejne pockam :)

[Petr Fiedler]

Proč chceš čekat, když s 1 úložištěm write hole nehrozí?

[k3dAR]

protoze druhej test sem delal s 1 ulozistem pred par mesici a byl problem jeste nez sem tam nakopiroval data ("shovavalo" mi to vytvorene subvolumes kam sem nahral par GB a rebootnul a chtel je znovu pripojit, zabral az nekolikatej nastroj na opravdu a to ted kterej se u btrfs ma pouzivat az v pripadu krize)

[k3dAR]

jeste sem teda prejmenovaval po vytvoreni ty subvolumes, to mi ale "zastancema" btrfs bylo vysvetleno ze problem udelat "nemohlo"...

[Petr Fiedler]

No to jsi mě tedy moc nenadchnul. Nemohl jsi udělat něco špatně?

[k3dAR]

teoreticky mohl, ale protoze sem delal jen:
- format
- vytvoreni nekolika subvolume
- zkopirovani par GB dat do nekolika subvolume
- primountovnai subvol
- prejmenovani subbolume a presunuti do jineho adresare
(vse vychozi nastroje a hodnoty)
tak nevim co :) disk je ok, smart v poho i po smart long testu...
proste sem usoudil ze mam jeste pockat :D

[Aleš Kapica]

Někdo je holt umělec.

[Petr Fiedler]

Dělá ti to dobře?

[k3dAR]

a vis co/zda sem udelal neco spatne, nebo mas jen blbe kecy?

[Aleš Kapica]

Mám blbé kecy, protože za celou éru co btrfs používám a že ho používám už fakt dlouho, se mi nic podobného nestalo.

[k3dAR]

skoda, protoze by me opravdu zajimalo co sem mohl udelat spatne ze se to takto zachovalo

[Petr Fiedler]

Polož dotaz. Mě by to taky zajímalo.

[Heron]

Tak napiš přesný postup, jak se do toho stavu dostat (sám píšeš, že je to málo kroků, takže zreplikovat ten postup nemůže být problém) a až potom se máme o čem bavit.

Diskusí typu "něco jsem udělal a ono se to rozbilo" je plný internet. Přičemž jednak ani není jasné co konkrétně udělal a hlavně, jestli se to skutečně rozbilo.

[k3dAR]

nepsal sem "neco sem udelal" uznavam ze nejsou vypsane prikazy, pokud si vzpominam tak:

# zformatovani
mkfs.btrfs /dev/sdXY

# primontovani korenu
mount /dev/sdXY /data.hddB

# vytvoreni subvolume
mkdir /data.hddB/.subvolumes
btrfs sub create /data.hddB/.subvolumes/@Devel

# zkopirovani par GB dat
cp -a /data.hdd/Devel/neco /data.hddB/.subvolumes/@Devel

# primontovani subvolume
mkdir /data.hddB/Devel
mount -o subvol=.subvolumes/@Devel /dev/sdXY /data.hddB/Devel

# prejmenovani subvolume
mv /data.hddB/.subvolumes/@Devel /data.hddB/.subvolumes/Devel

# prejmenovani adresare s subvolumes
mv /data.hddB/.subvolumes /data.hddB/.subvol

# pridani do fstab
UUID="11111111-2222-3333-4444-555555555555"     /data.hddB/Devel        btrfs   defaults,subvol=.subvol/Devel               0       0

# reboot
reboot

V /data.hddB/Devel pripojeno nebylo, neslo ani pripojit rucne (neoznamilo zadnej error), v /data.hddB/.subvolumes/Devel bylo prazdno uz si nevzpomenu jake nastroje ci parametry sem pouzil, nasel sem si nejake howto s poradim jak se maji zkouset, nakonec zabral az tusim "btrfs --repair /dev/sdXY" (kterej se mel pouzit az v "krizovem" pripade...

V podstate mi slo o to zda muze vadit pri primontovanem subvol jeho prejmenovani a/nebo prejmenovani adresare v kterem se nachazi, protoze vsechno ostatni bylo jak sem psal s vychozima/zadnejma parametrama

[k3dAR]

jeste premyslim, zda sem nahodou nevytvoril subvol kterou pak misto "btrfs sub delete.." smazal ciste v mc jako by slo o adresar, coz sem ted vyzkousel a smazat to jde a "btrfs sub list" ji pak neukaze, i kdybych to pretim neudelal => otazka: muzu naborit btrfs tim ze smazu subvol jako by slo o normalni adresar???

[Heron]

Od verze 4.18 je možné dělat na subvolume rm nebo rmdir. Jenže na rozdíl od btrfs sub del to udělá přesně to, co ten nástroj dělá na normálním adresáři, tedy rekurzivně smaže všechny soubory a až potom smaže ten root adresář (subvolume). Asi to tam mají jen z důvodu lepšího chování "jako adresář", ale plné subvolume je lepší mazat pomocí btrfs sub del, protože je to pro user space mnohem rychlejší (hned) a potom na pozadí běží kernel proces btrfs cleaner. (Toto je další důvod pro použití subvolume: pokud vím, že budu pracovat s velmi mnoha soubory, tak je lepší to potom smazat jako celek, protože na rm bych taky mohl čekat několik dnů.) Ale rozhodně to není tajná funkce na zničení fs. Jo a před verzí 4.18 to na rm prostě napíše (4.9):

rmdir aaa
rmdir: failed to remove 'aaa': Operation not permitted
rm -r aaa
rm: cannot remove 'aaa': Operation not permitted

Co se týče přejmenování namountové subvolume nebo její cesty, tak se taky nic neděje:

mount:
/dev/disk on /mnt/btrfs type btrfs (...subvolid=5,subvol=/)
/dev/disk on /mnt/btrfs/devel type btrfs (...subvolid=256,subvol=/subv/devel)

mv subv/devel subv/xxx

mount:
/dev/disk on /mnt/btrfs type btrfs (...subvolid=5,subvol=/)
/dev/disk on /mnt/btrfs/devel type btrfs (...subvolid=256,subvol=/subv/xxx)

mv subv subvols

mount:

/dev/disk on /mnt/btrfs type btrfs (...subvolid=5,subvol=/)
/dev/disk on /mnt/btrfs/devel type btrfs (...subvolid=256,subvol=/subvols/xxx)

Tj tento návod nevede k rozbití btrfs. Přežije to jak přejmenování samotné subvol, tak i cesty k ní. mount ukazuje správně aktuální cestu. Interně je to stejně mountované přes subvolid.

mount pro přehlednost ukazuje obě varianty a i když to namountuju přes subvolid, tak mount k tomu navíc zobrazí aktuální cestu k té subvolumě.

[k3dAR]

podobne sem si to pak take overoval, jen si nebyl jistej ze to ze "to de" znamena ze "to nevadi" :) zkusim tedy cely disk pro jistotu premazat, vytvorit znovu gpt, 1 oddil, naformatovat btrfs a v korenu rovnou subvolume tak jak sem je puvodne tam chtel montovat, nakopiruju data z ext4, rebootnu a uvidime :)

jinak mam tam jadro distribucni *buntu 20.04.2 5.8.x (pretim to na 99% bylo distribucni 5.4.x) a distribucni btrfs-progs 5.4.1, doporucujes zkompilovat btrfs-progs 5.8.x ? nebo nahodit (ubuntu)mainline jadro 5.11 + btrfs-progs 5.10 (5.11 asi nevyslo jeste)? ci mainline 5.10 + btrfs-progs 5.10 ? resp. je potreba k verzi jadra mit parovane verzi btrfs-progs? :)

[Heron]

Já verzi ničeho neřeším. Používám BTRFS kontinuálně od roku 2010, prošel jsem všechna distribuční jádra od 3 do 5 (ve skutečnosti i backport do centos5 takže nějaká 2.6?) a prostě to funguje. Já ani moc nevím, jaké tam jsou změny, pro moji potřebu (tj mirror multidevice) funguje všechno od samého počátku. Nejvýznamnější změna, která se mi hodí, je vícenásobný mirror (raid1c3). Takže bych na verze zapomněl a nic bych nekompiloval.

Jak tak čtu ty úvahy v tom druhém odstavci, tak si dovedu představit, že právě toto může vést k problémům. Kompilovat jádro a k tomu zvlášť utils, míchat verze, no nevím, jestli je to cesta ke stabilitě. Prostě se spolehni na distribuci.

[LarryL]

prošel jsem všechna distribuční jádra od 3 do 5

Jaké používáš distro?

[Heron]

Debian. Někde stable, někde (old)old stable (takto jsem zjistil, že mi na jednom serveru běží kernel 4.9 ), někde testing.

Já jsem admin, já verze neřeším. Dokud má distro bezpečnostní update a vše funguje, tak to nechám běžet. Na desktopu mám teda testing (5.10).

[Aleš Kapica]

Já jsem admin, já verze neřeším. Dokud má distro bezpečnostní update a vše funguje, tak to nechám běžet.

To se těžko někomu něco vyvrací, když se všude po netu válí zkušenosti, poznatky a rady co za sebou trousí domácí kutilové.

[k3dAR]

[...] Jak tak čtu ty úvahy v tom druhém odstavci, tak si dovedu představit, že právě toto může vést k problémům. Kompilovat jádro a k tomu zvlášť utils, míchat verze, no nevím, jestli je to cesta ke stabilitě. Prostě se spolehni na distribuci.

jadro sem nemyslel kompilovat, ale pouzit jiz pripravene z UbuntuMainlineBuilds (to bezne pouzivam na NB s SecureBoot, protoze distribucni jadro ma umyslne/umele omezene aby s SecureBoot NEsla hibernace), ty 2x3TB mam ovsem na desktopu kde nehibernuju takze nutnost to tam neni...

prave to "michat verze" sem si nebyl jistej, kdyz distribucni btrfs-progs je 5.4.x coz mi prijde parove k puvodnimu jadru Ubuntu 20.04 5.4.x, kdezto diky HWE je to distribucni jadro (aktualne) povysene na 5.8.x, tak jestli by nebylo vhodnejsi mit i btrfs-progs "stejne" rady :)

[Petr Fiedler]

A to nebyl convert (nebo jak se to jmenuje) jako prvně, jo? Prostě testovací instalace, vytvořil jsi nějaké subvols, zkusmo nakopíroval nějaká data a neklaplo to, jo?

[k3dAR]

nn, prvne convert, tohle ne, nebyla to instalace, ale zkouska datoveho disku - puvodne byl v mdadm/lvm/ext4 raid1, to sem degradoval na single a ten uvolnenej zkousel s btrfs s tim ze sem pak chtel samozrejme prejit z mdadm raid1 na btrfs raid1, ale po tomto divnem chovani sem to odlozil :) je fakt ze na tom stroji mam LTS jadro, takze priste zkusim s mainline jadrem + btrfs nastroje asi take posledni k danemu jadru (pokud budou a je to potreba :)

[Heron]

Hele a nestalo se to potom rebootu proto, že ten mdadm rozpoznal ten disk jako svůj member a nezačal to opět syncovat? Tj opravdu byla vymazána všechna metadata před samotným vytvořením nového oddílu s btrfs? Nezůstal náhodou typ partišny raid autodetect nebo něco podobného?

Protože víše zmíněný postup jednak nevede k poškození fs (celkem logicky) a bylo by vůbec divné, kdyby byl poškozen on disk formát takovým způsobem, že by to chtělo repair.

[Heron]

Tve někdy bych zabíjel za možnost editovat komentáře. Moje češtinářka se musí v hrobě obracet... Pokaždé si toho neomylně všimnu přesně v okamžik, kdy stisknu tlačítko dokonči. Náhled na to nějak nezabírá.

[k3dAR]

bohuzel nestalo :) pred reformat na btrfs, sem disk regulerne odebral z pole a pustil mdadm --zero-superblock /dev/sdXY...
jinak disk mam jeste k dispozici ve stavu po te oprave, bohuzel logy sem si nezazalohoval a uz jsou odmazane...

[Andrej]

1. Write hole je na mdadm / dmraid nesrovnatelně horší problém než na Btrfs. Takže: S čím srovnáváš? Jaký máš baseline? Co přesně je ten nedostižný ideál bez write hole? Snad leda ZFS, ale Btrfs už taky dávno umí raid5/6 konfigurace bez write hole.
• Tvrdíš tedy, že mdadm a dmraid nejsou production-ready? Ano, s tím souhlasím, jenže spousta uživatelů je (naivně) používá, jako by byly production-ready.
• Jo a mimochodem, jakýkoliv hardwarový AID (bez R) bez baterie taky není production-ready, protože má mnohem horší write hole problém než Btrfs. (Překvapuje mě, že to tolika provozovatelům AID řadičů vůbec nevadí.)
2. Díky konfiguraci raid1c3 (a raid1c4, ač v praxi není potřeba) už write hole na raid5/6 datech neexistuje; stačí mít raid5 / raid6 data v kombinaci s raid1 / raid1c3 metadaty a celý pseudo-problém zvaný write hole je definitivně pryč.
3. A vůbec, write hole na Btrfs je v podstatě „akademický“ konstrukt, který nikdo nikdy nikde nepozoroval v praxi. (Jasně, asi by se to dalo vyvolat v pečlivě sestavené simulaci.) Vyžaduje to velmi vzácnou a specifickou sérii událostí, restartů, selhání disků atd. Proč se někdo pořád něčím takovým ohání jako ztopořelým klackem, když Btrfs je už dávno nesrovnatelně bezpečnější než mdadm / dmraid, kde write hole hrozí mnohem akutněji?

Sorry jako, ale celý anti-Btrfs FUD už je výsostně trapný a ohraný. Možná tak před 5 lety to bylo skoro i vtipné, ale dnes už si říkám: Nebylo by načase, aby FUDisté trochu dospěli a přestali opakovat nesmysly?

takze u zakaznika kde mam RAID6 nasazeni ani teoreticky nehrozi, nicmene pro nasazeni me kdy by slo bud o 1 disk, nebo raid1 s 2 disky je to samozrejme irelevantni, nicmene jeste s 3 pokusem s btrfs asi stejne pockam

Zákazník by se měl raději obrátit na nějakou konkurenci, která chápe, jak tenhle svět funguje.

[k3dAR]

- hochu, hochu... nejde o anti-btrfs FUD, protoze informace sem cerpal z https://btrfs.wiki.kernel.org/index.php/Status
- za 10+ let pouzivani mdadm sem s nim problem nemel, ani pri vypadku disku...
- svet opravdu NEfunguje podle (fanatickeho) Andreje

[Heron]

Skvělé početní k tématu je tohle vlákno. Pravda, je dlouhé, ale stojí za to. Uživatel tam viní Btrfs z kdečeho. („Why is Btrfs so unstable?”) Jenže pak najednou přijde otázka roku:

…is the drive that this file system is on the same drive as in this reported thread?

To je bomba

Jenže uživatel měl dojem, že s Ext4 přece všechno „fungovalo“. (A že na vině musí nutně být software, nikoliv jeho disk.) Inu, pokud někdo pod pojmem „fungovat“ rozumí „potichu ztrácet data a nic nehlásit“ (jako Ext4), to je potom těžké.

No, jenže tento přístup nemají jen uživatelé na PC, v realitě jsem narazil na to, že někdo tvrdil, že se dělá zbytečně moc revizí, protože potom se tam nalezne více chyb... No ano, to je účel.

Nebo na jednoho známého, který když před x lety na moji radu zapnul smart testy, tak prohlásil, že ty testy ničí disky, protože už mu jich x označilo jako vadné a nikdy před tím tolik vadných disků neviděl.

Je to marný, je to marný, je to marný.

[Andrej]

Přesně tak.

Nedá se nic dělat. Počítačová demence (nebo zkrátka myšlení zaseknuté v době před 10 až 20 lety) postihuje stále častěji i jinak chytré a vzdělané lidi.

Například jeden můj známý měl cca v roce 2018 na výběr mezi ECC a non-ECC RAM, protože jeho motherboard podporoval obojí. Koupil si „samozřejmě“ non-ECC, protože ECC „přece“ všeho všudy jenom otravuje uživatele různými „zbytečnými“ chybami a restarty, které na non-ECC „přece“ „normálně“ nejsou, protože non-ECC „prostě funguje“ a neotravuje „normálního“ uživatele „zbytečnostmi“.

Ach jo. Kdyby tak blbost nadnášela…

Mně například ECC zachránil už několikrát domácí server a data na něm. Problém odhalil včas. Dřív, než selhávající paměť zničí Btrfs nebo něco dalšího. Jenže podle některých je lepší o takovém problému vůbec nevědět, spoléhat na šťastnou náhodu a hrát ruskou ruletu s vlastními daty.

S Btrfs je to podobné. Místo aby měli uživatelé radost, že Btrfs přistihl jejich totálně rozbitá zařízení při ztrátách dat a že odteď budou mít lepší přehled o tom, v jakém stavu jsou jejich data a zálohy, najde se pořád ještě tu a tam tvrzení, že nejlepším řešením je pštros s hlavou v písku.

[Heron]

Tak ono je to v podstatě jako s nemocemi. Spousta lidí nejde k lékaři, protože nechtějí slyšet špatnou diagnózu o které třeba tuší. Jenže za chvíli už může být pozdě. Je to iracionální přístup, ale psychika je také součástí člověka.

[LarryL]

Mně například ECC zachránil

Jen takové dotaz. Jak ti to v dmesg hlásilo "charon kernel: [Hardware Error]:", tak taková hláška by se ti tam objevovala i pokud by se nejednalo o ECC RAM?

domácí server

Klobouk dolů. 128GB RAM, 32 CPUs, on the AMD GPU and also on the NVidia eGPU, to je slušnej domácí servřík.

[Andrej]

Jen takové dotaz. Jak ti to v dmesg hlásilo "charon kernel: [Hardware Error]:", tak taková hláška by se ti tam objevovala i pokud by se nejednalo o ECC RAM?

Ne. Vůbec by se neobjevovalo a nenápadně a potichu by to „vytvářelo“ poškozená data.

Na Btrfs by to s velkou pravděpodobností znamenalo, že by pak najedou někde neseděly checksumy a poškodilo by to (v nejhorším případě) celý filesystém. Podle typu redundance a fáze kešování, ve které k poškození dojde, by se to pak dalo (nebo taky nedalo) obnovit z redundance.

Na jiných filesystémech by to prostě nenápadně žralo a poškozovalo moje data a dokud by se to nedotklo (většinou checksumovaných) metadat, vůbec bych nevěděl, že se to děje.

No a pokud by to postihlo anonymní paměť, tj. haldu nebo zásobník nějakého procesu, proces by buď někam nenápadně psal zničená data, nebo by tu a tam z nevysvětlitelných příčin odletěl.

Klobouk dolů. 128GB RAM, 32 CPUs, on the AMD GPU and also on the NVidia eGPU, to je slušnej domácí servřík.

On je to hlavně taky navíc desktop. Například NVidia eGPU se dá svěřit do výhradní péče KVM virtuálním strojům a může mít své vlastní monitory atd. a fungovat docela autonomně. Celkem tam jsou tři 5k monitory, z nichž každý se interně tváří jako dva monitory 2560×2880, takže ta paměť a dobrá grafika se občas hodí.

[pavele]

A k čemu ten stroj využíváš? Jsi programátor nebo pronajímáš virtuály?

[Andrej]

Využívám ho málo. Většinou u něj vysedávám a chlastám. A dívám se na sněžné opice, které jsou v 5k. (Jiného 5k obsahu je pořád poměrně málo. V roce 2016, když jsem kupoval 5k monitory, jsem si říkal, že tak do roka bude YouTube v 5k. Což se až tak úplně nestalo.)

Virtuály nepronajímám, ale hojně si s nimi hraju.

Jestli jsem programátor, to nevím.

[LarryL]

Na ECC RAM zatím nebudu přecházet i proto, že bych musel změnit MB, CPU a navic je to jen "desktop", ale díval jsem se jestli neexituje nějaká možnost, aby btrfs odhalilo nebo zvýšilo šanci na odhalení vadné RAM. Nenašel jsem, ale u ZFS prý existuje unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10):

This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.