fsck non fsck (impossibile impostare i flag di superblock)

A seguito di un arresto impuro su un dispositivo basato su scheda SD, ho portato la scheda SD fscknel filesystem di root. Ciò ha portato a variazioni su quanto segue:

e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2

Qui ho risposto "no" entrambe le volte ma non esiste una sequenza di sì / no che non porti immediatamente allo stesso risultato.

Il filesystem può essere montato e su ispezioni casuali sembra a posto; funziona anche bene nel dispositivo, e questo è il filesystem di root (in realtà si è rivelato non abbastanza bene, vedi commenti; tldr alcune directory irrimediabilmente corrotte).

Avevo ddla partizione (8 GB) in un file e ho provato fsck su quello. È interessante notare che:

e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)

Un successivo fsckpassaggio pulito, l'immagine può essere montata, e anche fsck -fdopo passa.

Ma il filesystem sulla scheda da cui è stata creata l'immagine della copia a blocchi grezzi presenta ancora lo stesso problema, tranne per il fatto che quello systemd-fsckche si verifica durante l'avvio registra il filesystem come "pulito". Successivamente, un corretto arresto, estrarre la scheda e fsckriprovare da un'altra casella presenta lo stesso errore.

Ogni volta che l'originale viene montato su un'altra macchina, note syslog:

kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete

Dal momento che ho eseguito il backup di tutto, sono aperto a provare qualsiasi cosa qui. Potrei semplicemente dimenticarmene e ripristinare la partizione dall'immagine apparentemente fissa, ma non sembra una soluzione molto soddisfacente, dal momento che significa assumere fsck cripticamente fallito nel risolvere un problema dall'aspetto minore.

Ho il sospetto che questo si trasformerà in una domanda "richiesta di documentazione ufficiale" riguardante cose come bisogni recovery_flag (o semplicemente una domanda "Cosa significa?"), Quindi ogni suggerimento in tal senso è apprezzato.

ext4 fsck sd-card

— goldilocks
fonte

Qualcosa nel kernel registra gli errori del dispositivo? Non sarebbe la prima volta che una scheda SD diventasse improvvisamente di sola lettura.

— Mark Plotnick,

@MarkPlotnick No, ed è scrivibile. L'ultima cosa nel registro prima del problema era il riavvio del sistema (il dispositivo è senza testa e non risponde dopo un lungo periodo apt upgrade). Dopodiché registra un avvio normale - e systemd-fsck dice "clean" (lo modificherò in), ma provare fsck al di fuori di quel contesto non riesce ancora.

— Riccioli d'oro

Il tuo fsck sulla copia ha cancellato 4 inode, ma ha corretto il conteggio degli inode liberi riducendolo di 2453 inode! È enorme. Verifica che il dispositivo riceva energia sufficiente.

— Meuh

@meuh noto che ogni volta che è montato sul syslog big box si riferisce a quei 4 inode (modificati in precedenza). Alcune cose su fs si sono rivelate incasinate (moduli del kernel aggiornati! \ O /), quindi ho bruciato una nuova scheda e rimarrò su quella vecchia nel caso in cui avessi la possibilità di approfondire ulteriormente. Non è esattamente una novità: una scheda di classe 10 per un portaoggetti senza marchio, in uso (leggero) 24 ore su 24, 7 giorni su 7, per alcuni anni, quindi ... Non credo che ci sia modo di verificare che una scheda SD sia definitivamente dismessa , ma suppongo che potrebbe essere quello. Il potere dovrebbe essere a posto ma potrebbe essere incerto in determinate condizioni.

— Riccioli d'oro

Non fa davvero schifo quando lo stesso strumento che dovrebbe risolvere il tuo problema, non funziona a causa della natura del problema? Conclusione: lo strumento non funziona e deve essere corretto.

— Marc.2377,

Risposte:

Ho appena incontrato questo stesso problema. Dopo aver eseguito il debug del problema con il e2fsckmanutentore, ci siamo resi conto che la scheda SD era rotta. Stava accettando le scritture senza errori, ma in realtà non stava scrivendo i dati sulla scheda. La scheda SD è stata effettivamente di sola lettura.

Sembra che la scheda fosse entrata in una sorta di modalità di sicurezza, in cui i dati potevano ancora essere letti, ma nulla di scritto.

Il e2fsckmessaggio unable to set superblock flagsindica che ha tentato di scrivere sul superblocco per contrassegnare il giornale come elaborato, cosa che è accaduta senza errori, ma quando è andato a rileggere nuovamente il superblocco indicava ancora che il giornale doveva essere riprodotto. In altre parole, le modifiche scritte sul superblocco non sono state salvate sul supporto di memorizzazione.

La scheda che sto usando che ha questo problema è una microSD Samsung Evo da 16 GB, che cito solo nel caso in cui sia un problema comune con queste schede.

Sono stato in grado di testarlo usando ddper scrivere 4096 byte dalla /dev/zeroscheda al blocco 0, quindi ho letto dalla scheda e invece di ottenere tutti gli zero come dovrei, ho ancora ottenuto il superblocco ext4 immutato originale.

Ora sto trasferendo i dati su una nuova scheda e poi vedo se posso ottenere una sostituzione da Samsung, che sembra offrire una garanzia di 10 anni sulle schede SD.

AGGIORNAMENTO: Samsung ha sostituito la scheda da 16 GB con una da 32 GB della stessa serie Evo, quindi suppongo che non mi possa lamentare troppo!

— Malvineous
fonte

"dove i dati potevano ancora essere letti, ma nulla di scritto" -> La fs era scrivibile.

— Riccioli d'oro

@goldilocks: Suona come se il tuo superblocco fs non fosse stato scrivibile. Inoltre, la mia fs è apparsa scrivibile grazie alla memorizzazione nella cache, solo dopo aver smontato e rimontato ho notato che eventuali modifiche andavano perse.

— Malvineous,

Non era un'illusione dovuta alla memorizzazione nella cache.

— Riccioli d'oro

So che questo è un vecchio thread, ma, ho pensato che avrei offerto alcune intuizioni.

Questo sembra essere il modo in cui le carte SD muoiono per morte naturale. Il numero di cicli di lettura / scrittura che le schede SD possono sopportare è sostanzialmente inferiore rispetto alla maggior parte degli altri supporti considerati "lettura / scrittura". Quando questo è esaurito, la carta entrerà in modalità di sola lettura, ma non ti informerà di ciò. Molte cose penseranno che stanno scrivendo sulla scheda grazie alla cache del sistema operativo, ecc., Ma nulla si attacca mai.

Un ottimo modo per uccidere una scheda SD è montarla come una partizione di swap o qualcosa che richiede molta lettura / scrittura. Saresti sorpreso di quanto velocemente puoi uccidere una carta in quel modo. Ho scoperto che eseguire Knoppix da una scheda SD o una chiavetta USB durerà solo un mese o due, a seconda della qualità della scheda e dell'intensità dell'utilizzo di Knoppix. (Da allora sono passato a far girare Knoppix da un drive SSD USB che dura da un paio d'anni).

— Joe
fonte