Dotaz: Hroutí se karta

[lertimir]

Mám jen ujištění se analýzy. Možná to už někoho z vás potkalo. Dnes jsem při připojení na RPi3B na chalupě, která mi dělá monitoring a pro manželku zálohy, zjistil, že sice běží, externí HDD je připojen, ale root filesystem je read only. V journalctl jsem našel:

Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error: 59 callbacks suppressed
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_mb_generate_buddy:1098: group 56, block bitmap and bg descriptor inconsistent: 19855 vs 19803 free clusters
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs (mmcblk0p7): Delayed block allocation failed for inode 141633 at logical offset 6 with max blocks 1 with error 117
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs (mmcblk0p7): This should not happen!! Data will be lost
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs (mmcblk0p7): Delayed block allocation failed for inode 465123 at logical offset 0 with max blocks 1 with error 117
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs (mmcblk0p7): This should not happen!! Data will be lost
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_ext_remove_space:2997: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max >
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_ext_remove_space:2997: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max >
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_find_extent:936: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max 31241(>
Jun 12 04:00:53 raspberrypi kernel: EXT4-fs error (device mmcblk0p7): ext4_ext_remove_space:2997: inode #132305: comm rs:main Q:Reg: pblk 921697 bad header/extent: invalid magic - magic 32e6, entries 19412, max >
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: file '/var/log/kern.log'[11] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: Structure needs cleaning [v8.2102.0 try https://>
Jun 12 04:00:53 raspberrypi rsyslogd[447]: action 'action-3-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try htt>

a pak chyby jedou dále. Znamená to podle mne, že se hardwarově hroutí karta a než se tam fyzicky dostanu, vyměním ji a přenesu na ni zálohovaný systém, tak vzdáleně nemohu nic dělat.

---

---

Odpovědi

[X]

Vidim velky spatny. ;)

[trubicoid2]

Ta karta nemusí být úplně kaput. Spíš se na ní jen rozsypal FS. To na těch kartách dělá docela často. Lepší je použít USB SSD, nebo kombinaci s RO FS na kartě.

[PetebLazar]

Pokud nejsou nároky na kapacitu rPi OS filesystému velké (kvůli horšímu poměru cena/kapacita) mohou být alternativou i industrial uSDHC orientované na výdrž (v dnešní době typicky postavené na TLC flash pamětech běžících v pseudo-SLC modu). U nich deklarovaných 30K P/E, pokud jsou reálné nás "vrací do doby" mezi SLC a MLC. https://www.kingston.com/en/memory-cards/industrial-grade-microsd-uhs-i-u3?partnum=sdcit2%2F16gb

Nechápu, proč dtto samé (tj. práci SSD čistě v režimu pseudo-SLC i za cenu 3x nižší kapacity) aspoň volitelně (změnou Firmware) nenabídnou výrobci SSD. Dnešní řadiče toho prokazatelně schopny jsou, nakonec na tomto principu funguje u dnešních SSD tzv. "SLC-cache".

[lertimir]

OK. tahle by mi stačila ale při srovnání ceny mé srdce pláče. Zkusim spíše samostatné externí SSD a nějaký mám i volný. Ostatně na rpishopu nemají skoro žádné RPI samostatně, jen sady. Bohužel se na chalupu nedostanu dříve než za 10 dní a proto jsem RPi raději vzdáleně vypnul.

[Max]

Používám Sandisk MicroSD karty (teď stojí dvě stovky v 16GB verzi?) v našich průmyslových arm deskách a na 10ks eviduji po asi 9 letech 0 odešlých microsd karet, nebo nabořeného fs atd. Prostě nic. Naladil jsem jen debian, všechno, co zapisuje, jsem nahodil do ramdisku a no problemo seňore... Je to nesmrtelný, běží to venku, v zimě krutá zima, v létě krutý horko.
Dřív jsem používal Kingstone, ale od těch jsem utekl, byly poruchový.
Zdar Max

[PetebLazar]

Utéct k read-only režimu není žádným "hrdinstvím", překonat odpor, strach a donutit se zaplatit navzdory vražednému poměru cena/kapacita dostatečně velkou "industrial" SD ano.

[Max]

Já to ale nemám v read-only režimu. Jen jsem dal do ramdisku /tmp a /var/log :).
Zdar Max

[PetebLazar]

U te 64GB Kingston Industrial je deklarovan TBW 1920TB (64GB x 30000). U te 16GB to patrně bude cca 1/4 tj. 480TB. U toho 240GB SSD to výrobce raději ani nesdělí. Pokud bychom vycházeli z hodnot jiných TLC SSD této kapacity bude to pravděpodobně někde okolo mezi 80-150TB. Cenově s SSD srovnatelná 32GB varianta tak na s odhadovanými 960TB může být ve výdrži až 8x lépe.

[lertimir]

Díky za nakopnutí. Ještě to zvážím, ale asi i Endurance https://www.kingston.com/en/memory-cards/high-endurance-microsd-card by mohla stačit. Přece jen Industrial chápu tak, že navíc tam mají teplotní odolnost. A pokud to chápu, tak Endurance by měla ustát fullHD video zápis 24/7 po 3 roky. Tolik do ní asi nikdy nezapíšu.

[PetebLazar]

Myslím, že Endurance karty nejedou v pseudo-SLC modu, ale TLC. Takže to není pouze o teplotní odolnosti. Také čtyřikrát vyšší max. kapacita 256GB versus 64GB Industrial a nižší zápisové rychlosti u nich naznačují vícebitové využití cell.

[lertimir]

Myslel jsem to tak, že tolik dat, co tvrdí u endurance, stejně nezapíšu. Pokud z TLC udělají SLC, tak primárně zvyšují odolnost proti šumu, ať již vzniká vysokými teplotami, nebo sníženou odolností hraničních bariér při opakovaných zápisech. Souhlasím, že to, co má industrial je fakt hodně, je to i mnohem více než má obvyklé 1TB NVMe disk.

[PetebLazar]

Já to pochopil tak, že ty Endurance jsou mířeny na "trvalý" sekvenční zápis, dohledové kamery atd. Což je přecijen odlišný způsob zátěže, než v živý OS. Nakolik je mezi SSD, Industrial, Endurance srovnatelný wear-leveling si nedovolím odhadovat. Pro kapacitně nízkonárokové r-Pi aplikace mi Industrial s pseudo-SLC přišla v té dnešní TLC-bídě jako zajímavá volba.

[lertimir]

Konečně jsem na chalupě a řeším RPI. První poznatek je ten, že asi moc zhroucené karta nebyla. ddrescue přečetl vše, i když na první průjezd skákal, ale pak přečetl zbytek.

Druhý poznatek je k Industrial kartě. Uvidím, jak bude sloužit, protože na kartě byl jeden oddíl FAT32

 file -s /dev/sdc1
/dev/sdc1: DOS/MBR boot sector, code offset 0+2, OEM-ID "        ", sectors/cluster 64, reserved sectors 1056, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 8192, sectors 62791680 (volumes > 32 MB), FAT (32 bit), sectors/FAT 7664, serial number 0x554924d4, unlabeled

A trochu se obávám, že vysoký zápis může být dělán tak, že na oblast FAT tabulky bude technologicky nasazen jiný typ chipů než na zbytek karty.

Třetí poznámka původní karta od RPi byla Sandisk.

[PetebLazar]

Tomu se mi nechce věřit. Dnes jde prakticky vždy o TLC flash, pouze Industrial karty je provozují v režimu pseudo-SLC (některé možná pseudo-MLC).

Wear-leveling sám snad nemá tušení o stavu/typu FS. Nakonec i při TRIMu je to myslím FS kdo sděluje storage, které bloky jsou jím nepoužity a mohou být tudíž předem připraveny na budoucí zápis.

[lertimir]

Jasně, to nerozporuji. Ale na druhou stranu máš v zásadě dva druhy dat/obsazených sektorů. První jsou běžná data, a v zásadě do bežných dat patří i adresáře. A pak máš alokační strukturu. Tedy systém, který ví, které sektory jsou volné, které jsou obsazené a jak (jak soubor postupně pokračuje přes sektory). Ty struktury jsou různé, podle typu filesystému a i jsou rozmístěny různě na disku. Informace v této alokační struktuře se přepisují řádově (možná několikařádově) častěji. A pak co s tím, buď to vyřešíš wear levelingem, kdy to se rozhází, nebo když tam wear leveling není, tak máš v podstatě jedinou možnost, specializovat se na filesystem a v prostoru jeho alokační struktury nasázet odolnější chipy. Takže otázka je jestli máme na industrial wear leveling? Kdysi (cca 10 let) jsem měl flash disk a zkusil na něm jet system (Debian) k domácimu serveru a asi po čtvrt roku klekl. Po reformátu na FAT byl znovu funkční a nebyly na něm ztráty dat.

[PetebLazar]

"Maximální" velikost FAT32 filesystému je 32GB (maximum SDHC), SDXC karty 64GB+ jsou továrně naformátovány na filesystem extFAT.

Když se do buněk napíšou nové hodnoty a flash paměť je udrží (rozlišení levelů/bitů) může se karta/FS jevit jako funkční, předchozí záznam patrně místně "vyčpěl", což se děje snad i pouhým opakovaným čtením (i intenzivní čtení se platí přepisy, obsah buněk se musí jednou za čas vymazáním/zapsáním původního obsahu obnovovat).

[lertimir]

Však jo, mám 32GB, podle file viz výše tam byl FAT. Uvidíme jak to dopadne.

Ta poznámka k flešce byla primárně k tomu, že po reformátu na FAT neměla se zápisem problém alokační struktura na FATu. Prošlo přes ni několik tisíců zápisu a přepisy obsazovaných clusteru ve FAT OK. A rychlost zápisu nebyly vzdálena od deklarované. Samozřejmě na ni šly už data jedině na přenosy, které mohly se kdykoli ztratit. Ale předtím na ext4 rychlost padala s časem a např když běžela aktualizace tak na konci před reformátem byla na desítkách kB/s a flash měl read chyby. Z toho usuzuji, že flash měla pro FAT area jiné chipy, a pokud se alokační struktura dostala jinam, výkon byl katastrofální a začaly vznikat chyby.

Ale to je již jedno. Problém je zatím vyřešen.

[trubicoid2]

A proč je to vlastně mmcblk0p7? Normálně to bývá mmcblk0p2, teda druhá partice na kartě. Je to tak schválně?

[Peter Golis]

Pravdepodobne je na mmcblk0p7 pripojený /var/log keďže niektorí ľudia stále rozdeľujú disk namiesto používania kvót. No neviem, ale radšej by som ten priečinok pripájal do RAM, a v prípade potreby by som si posielal logy na vzdialený server.

[lertimir]

Nevím, je to karta přímo od rpishopu tak jak jsem ji před lety koupil s default instalací a jenom jedu aktualizace.

[X]

Jak moc nutne potrebujes zapisovat?