Dotaz: BTRFS error state EAL - Debian 12 - 2x SSD

[Howard]

Jednou za 2-3 měsíce se stane, že se server zasekne a na obrazovce je hromada hlášek:

[2420966.279450] BTRFS error (device nvme0n1p2): bdev /dev/nvme0n1p2 errs: wr 1173, rd 2291, flush 0, corrupt 0, gen 0

Jedná se o Debian 12 se standardními repozitáři pravidelně aktualizovaný jednou týdně.
# uname -a
Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

Disky - 2x 1 TB Samsung SSD 990 PRO FS samozřejmě BTRFS, na jednom disku je boot, kořenový oddíl a swap. Druhý disk slouží jako rozříšení kořenového oddílu pomocí btrfs device add, tedy to funguje jako RAID 0.

Badblocks obou disků ani btrfs scrub neukázal žádné chyby. Journalctl -b -1 končí na opakující se takovéto hlášky:

bře 24 16:48:01 207 CRON[3484705]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
bře 24 16:48:01 207 CRON[3484706]: (root) CMD (/root/scripts/load_check)
bře 24 16:48:01 207 CRON[3484705]: pam_unix(cron:session): session closed for user root
bře 24 16:48:21 207 earlyoom[1226980]: mem avail: 45136 of 63436 MiB (71.15%), swap free: 12268 of 19066 MiB (64.34%)

Ani v žádném jiném logu jsem nenašel žádnou chybu, jako když prostě selže disk a systém chybu už nemůže zapsat na disk, pouze na obrazovku.

Zatím jsem neměl příležitost nechat běžet memtest ani btrfs check, server musí běžet. Doporučujete udělat memtest a btrfs check?

Může se jednat o bug v kernelu, i když se jedná o stabilní Debian? Mám zkusit nainstalovat jiné jádro?

Případně co dál řešit?

Odpovědi

[P.V.]

Mozna to chce rebalans.

Doporučujete udělat memtest a btrfs check?

A co bys tak očekával, že dostaneš za radu? Btrfs ti píše, že error... Tak pěkně na btrfs zkontroluj, co můžeš. Pak můžeš přemýšlet, jak postupovat dál.

[Aleš Kapica]

A jenom bych si přisadil. Prostuduj si také blogpost Všechno má svůj čas, speciálně pasáž „Proč nechci mít jen jeden disk”, kde máš odpověď i na otázku, co děláš blbě.

[Aleš Kapica]

Jo a taky nebude od věci když si přečteš blogposty, mého kamaráda: Případ zhrouceného notebooku a Nasysleno.

[Max]

Jakou verzi FW máš v těch NVMe?
Jaký chipset máš v tom serveru?
Zdar Max

[Want]

Jakou verzi FW máš v těch NVMe? Jaký chipset máš v tom serveru?

Vis podrobnosti o rozdilech ve verzich? kdyz ti rekne verzi co bude nasledovat za radu?

[Vantomas]

Prostá zkušenost se Samsung SSD. Mají v těch firmwarech bugy, že ta SSD na dlouho lagnou nebo se nějak zrestartují a zmizí/objeví se na sběrnici, když běží už příliš dlouho. A to samozřejmě filesystémy a jiný věci nemají rády. No a když pošle verzi, co je až moc příliš stará, tak se dá předpokládat, že problém bude tam.

[Max]

Můžu např. zjistit, že existuje novější verze fw. Nebo lze podle konkrétní verze dohledat, zda nemá nějaký problém.
Zdar Max

[Want]

Doufám Maxi, že ti je jasné že můj nick zneužívá nějaký šmudla. Nicméně - jsem nakloněn tomu dát pivko, takže jak budeš mít ideální okno, stačí echo.

[Want]

můj nick

ID? nebo staci byt ve strane?

Jen jestli se ty neskrýváš za nickem nějakého šmudly...

[Want]

Buď bez obav mantáku. Max ví na jaké číslo zavolat.

[X]

Nemuze byt problem s deskou? Nejaka diagnostika neni?

[lertimir]

Nějak vůbec nerozumím slovnímu spojení "server" a "RAID 0". Svým studentům už desítky let tluču do hlav, že jakýkoliv kus hardware může v kterýkoliv okamžik selhat, a tak že je naprosto neopravitelný. A když si přečtu toto, tak mám pocit s klasikem: Je to marné, je to marné, ne to marné.

[alkoholik]

Kde se sakra flaka Andrej?
Hadam, ze do NVMe error logu jsi se uz podival a jsou taky prazdne..

[pavele]

V případě chyby btrfs se Andrej nevyskytuje.

Samozřejmě všichni diskutující označí tazatele za absolutního amatéra, neschopného hlupáka, s vadným hardwarem - nevhodná základní deska, disky nevhodné pro btrfs, zastaralým softwarem, s nepoužitelnou distribucí a poradí mu, aby si raději najal firmu na opravu.

Tak jako už mnohokrát dříve.

[Max]

Pár lidí, co tu mělo rozpadlé btrfs, používalo zabugované Samsungy 960/970 řady, kde opravdu byla chyba v jejich fw a v kombinaci s určitými chipsety mohlo dojít ke ztrátě dat. V linux komunitě se to řešilo několik let a postupně se to vyřešilo tak, že u těch ssd vypínal kernel TRIM, NCQ a další věci.
V případě řady 990 Pro nevím o ničem, ale tazatel nekomunikuje, takže se asi příčiny nedopátráme. Je ale vidět, že ty máš hned jasno :D.
Zdar Max

[chinook]

Já mám asi ten stejný problém.

Model Number:                       Samsung SSD 990 PRO 4TB
Firmware Version:                   0B2QJXG7

Linux node 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 GNU/Linux

Co jsem se díval firmware je na webu novější, ale nenašel jsem, že by opravil tyto chyby. Disk je celkem dost vytížen. A po týdnu nebo dvou. Začne hlásit stejné chyby jak tady kolegovi. Restart PC dále disk nenajde. Ale pokud PC vypnu a zapnu, tak to zase nějaký týden jede v pohodě. Měl jsem podezření, že se to přehřívá, koupil jsem chladič otevřel case snížil teplotu o 20stupnu a furt stejný. Přemýšlím, že koupím jiný disk. Ale ještě tomu chci dát šanci. Pomohl by upgrade kernelu na 6x?

[Max]

Díky za info. Hele, v changelogu firmware nemusí být uvedeno vše. Je to na benevolenci vendora. Jinak už jen to, že po restartu nevidíš disk, je velký špatný. To by se dít opravdu nemělo. Buď máš vadný disk, nebo nějaký bug v desce, nebo těžko říci. Začal bych full updatem fw, tj. i biosu desky.
Teploty NVMe můžeš sledovat, např. 80C je už podle mě přes čáru. Já mám běžnou teplotu kolem 47C.
Pasiv používám, bez něj to nejde, ale taktéž to nejde bez průvanu ve skříni. Obzvláště, když má člověk nvme pěkně u výkonné GPU, která topí vostošest.

Hele, poměrně nový kritický bug v 990 Pro: Avoid Loss of Data: Upgrade Your Samsung 980 & 990 Pro SSD to the Latest Firmware (0E error fix).
Ale těžko říci, zda se ho ten bug týká, bo jinde vyráběný s trochu jinými čipy: Samsung 990 PRO Firmware 0B2QJXG7 is it okay?
Pokud je dostupný nový fw, tak bych rozhodně udělal update.
Jinak Debian má aktuálně kernel 6.1 ve stable větvi, takže řekl bych, že to je signál, nebát se do toho jít. Pětkový kernel už je opravdu dědeček.
Zdar Max

[chinook]

Uvidíme, již skoro týden mám aktualizovaný FW na desce od DELLu Precision 3650 Tower. Tuším z verze 1.12 na 1.30.

Jádro na: Linux node 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux

Disk je teď sice méně vytížen, protože po upgrade z debian 11 na debian 12 jedna aplikace, která to dosti vytěžovala přestala jet a nedokážu ji zprovoznit.

Teplota ssd disku je 41 stupnu bývala 45 když ještě běžela ta aplikace.

Zatím nedovedu posoudit jestli upgrade pomohl. Uvidíme časem. Disk jsem zatím neupgradoval, budu muset sehnat disk s win, abych tam nabootoval a upgrade provedl.

[Max]

Mělo by to jít i přímo z Linuxu: Samsung SSD Firmware.
Zdar Max

[chinook]

Super, přitom jsem hledal a nenašel to.

Update proveden.

Firmware Version: 4B2QJXD7

Teď ještě zrpovozním tu aplikaci co to vytěžuje a za cca 7-14 dní uvidíme.

[Max]

Díky, tak pak dej info.
Zdar Max

[chinook]

Tak to nepomohlo. Až budu u PC, zkusím to vypnout a zapnout a udělám badblocks test. Ale posledně to prošlo bez chyb. Dostanu se k tomu koncem týdne. Samotný restart nepomohl. Takže nevidím zase disk.

[chinook]

Tak jsem se tam ještě rychle otočil a počítač vypl a zapl. Disk naběhl bez problému. A testy také.

badblocks -s /dev/nvme0n1
Checking for bad blocks (read-only test): done


smartctl -a /dev/nvme0n1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-20-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 4TB
Serial Number:                      S7DPNJ0WB00736Y
Firmware Version:                   4B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 4,000,787,030,016 [4.00 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       2.0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          4,000,787,030,016 [4.00 TB]
Namespace 1 Utilization:            1,769,588,289,536 [1.76 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            002538 4b3140d97b
Local Time is:                      Mon May  6 15:59:33 2024 CEST
Firmware Updates (0x16):            3 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x0055):     Comp DS_Mngmt Sav/Sel_Feat Timestmp
Log Page Attributes (0x2f):         S/H_per_NS Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg *Other*
Maximum Data Transfer Size:         512 Pages
Warning  Comp. Temp. Threshold:     82 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     9.39W       -        -    0  0  0  0        0       0
 1 +     9.39W       -        -    1  1  1  1        0       0
 2 +     9.39W       -        -    2  2  2  2        0       0
 3 -   0.0400W       -        -    3  3  3  3     4200    2700
 4 -   0.0050W       -        -    4  4  4  4      500   21800

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        49 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    138,548,935 [70.9 TB]
Data Units Written:                 90,921,628 [46.5 TB]
Host Read Commands:                 710,869,727
Host Write Commands:                126,364,839
Controller Busy Time:               1,787
Power Cycles:                       340
Power On Hours:                     1,325
Unsafe Shutdowns:                   16
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               49 Celsius
Temperature Sensor 2:               50 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

[xxl]

Andrej tady už kolikrát psal, že chyby hlášené btrfs dost často upozorňují na vadný hardware, jako je třeba paměť. A i sám tazatel tušil, že problém nemusí být přímo v btrfs. Kromě toho tazatel také psal, že btrfs scrub skončil bez chyb. To znamená, že data byla patrně dosud v pořádku.

Takže bych netvrdil, že je to chyba btrfs.

[pavele]

Netvrdím, že je to chyba btrfs.

Tvrdím, že co se týče (nejen) btrfs, nikdy (poslední měsíce?) tu nebyla konstruktivní debata, která by vedla k vyřešení problému a pomohla tázajícímu.

Navíc si nejsem jist, jestli většina dotazů nejsou uměle vytvořené, aby to tu aspoň trochu žilo. Tazatel hodí otázku a pak se už neozve.

Před lety měli všichni snahu a ochotu problém vyřešit. Možná se mýlím.

[Jendа]

Kromě toho tazatel také psal, že btrfs scrub skončil bez chyb. To znamená, že data byla patrně dosud v pořádku.

Takže bych netvrdil, že je to chyba btrfs.

Klasický omyl. Scrub nekontroluje strukturu FS, ale jen checksumy bloků. Pokud k chybě (softwarové - race conditions, přepsání kusu paměti nesouvisejícím zabugovaným modulem…; hardwarové - bitflip v paměti) došlo před spočítáním checksumu, tak scrub projde, ale FS není konzistentní. K ověření konzistence slouží btrfs check. Čím ho pak opravit - těžko říct. btrfs-check má v manuálu napsáno že se nemá pro opravy používat. Nejspíš tedy vykopírovat data pryč, FS vytvořit znova, zkopírovat data zpět a doufat že to nebudeš muset dělat moc často. No, furt lepší než ZFS, kde fsck nemají vůbec, ani read-only variantu.

[Max]

No, nevím, ZFS mi přijde super. Rok se ho snažím zbořil a přijít o data, mám v poolu x vadných disků a pořád se to snažím nějak zneškodnit a čekám, kdy to padne. Jednou to mělo na mále (dvě RAIDZ skupiny se rozpadly), ale nakonec to stejně přežil a skupiny znovu sestavil a s datama nebyl problém. Celkově je to hodně drsně dobrý řešení.
Zdar Max

[xxl]

Klasický omyl.

Tak za prvé. Napsal jsem

data byla patrně dosud v pořádku.

protože si uvědomuji, že k podobné věci může dojít.

A za druhé. I pokud k nějaké

chybě (softwarové - race conditions, přepsání kusu paměti nesouvisejícím zabugovaným modulem…; hardwarové - bitflip v paměti) došlo před spočítáním checksumu

tak je to chyba btrfs pouze tehdy, pokud to btrfs sám způsobil. Což u většiny těch věcí, o kterých píšeš, neplatí. Kromě toho si myslím, že pokud by to dělal přímo btrfs, bylo by postižených víc.

Ovšem my nevíme, jak to v našem případě dopadlo, protože tazatel nekomunikuje.

[Max]

Ale máš tu chinooka, který potvrdil nějaký problém se stejným / podobným modelem Samsungu + linky na big fatal chybu ve fw.
Takže i když tazatel nekomunikuj, máme tu další případ se shodným modelem, který naznačuje problém na hw/fw úrovni.
Zdar Max

[xxl]

No jo, ale to přece není chyba btrfs.

Mimochodem, tyhlety chyby:

[2420966.279450] BTRFS error (device nvme0n1p2): bdev /dev/nvme0n1p2 errs: wr 1173, rd 2291, flush 0, corrupt 0, gen 0

jsem měl minulý týden v logu taky. Taky Samsung, ale 2,5' SATA. Ovšem kromě těchto chyb od btrfs mi to hlásilo i hw chyby v logu a také chyby při smart testech. Disk jsem vyreklamoval. Data, zdá se, v pořádku, měl jsem tam raid.

[Max]

Já jen reagoval na "Ovšem my nevíme, jak to v našem případě dopadlo, protože tazatel nekomunikuje.", čímž jsem chtěl říci, že vzhledem k dalšímu podobnému problému asi víme, odkud vítr vane.
Zdar Max

[chinook]

Ještě můžu spustit diagnostiku dellu, jestli neobjeví někde nějaké chyby. Spouštěl jsem někdy před čtvrt rokem, mám trochu problém se k tomu fyzicky dostat. A vše bez problému, to tam ještě nebyl tento disk. Takže nebyl důvod se tím zabývat.

Každopádně tam provozuji ještě 2x2,5 SSD disky také celkem vytížené tam problém není. Ještě jeden NVMe disk kde je systém, tam taky problém není.

Tzn. Bude problém buď v desce nebo něco s tím diskem. Asi to vyřeším tak, že místo toho koupím novej. Ale zase mně přijde škoda, vyhodit 4TB disk, když se zdá být v pořádku.

Podivné taky je, že když se ten disk odpojí, tak po restartu se nepřipojí. Až po vypnutí a zapnutí PC.

Dělá to i po upgrade FW na desce i v SSD disku.

[Jendа]

Nebyla jedna z hlavních propagovaných vlastností btrfs, že má díky svým checksumům proti chybám disku chránit (resp. je scrub má alespoň detekovat)?

[Howard]

Právě kvůli tomu, že první odpovědi ze mě dělaly blbce, jsem to tady už moc nečetl.

Zkusil jsem nainstalovat kernel 6.5.0-0.deb12.4-amd64 z repa bookworm-backports. Zatím to už běží měsíc bez problémů. Ale to nic neznamená, to běželo i na kernelu 6.1 bez problémů několik měsíců.

Někdo tu psal, že to možná běží na nevhodné distribuci. Jestli je Debian 12 nevhodná distribuce, tak já potom už nevím co.

Upgradoval jsem i BIOS na poslední verzi.

Nejspíš naplánuju i restart jednou měsíčně, čímž se vyřeší takové ty případy, že něco běží moc dlouho a dostane se do chybného stavu, taky se tu o tom psalo.

V tuto chvíli to dál asi řešit nebudu, dokud se to zase nezasekne (pokud).

Každopádně děkuji za všechny smysluplné odpovědi.

[xxl]

A jak dopadl btrfs check, memtest a smart testy?

[Howard]

Btrfs check jsem bohužel nepouštel.

Memtest - 4 hodiny - žádná chyba

Smart testy - pouze malé opotřebení disků, žádný problém

[chinook]

Co je myšleno smart testy?