fsck ne fsck pas (impossible de définir des drapeaux de superbloc)

Après un arrêt impur sur un appareil basé sur une carte SD, j'ai sorti la carte SD vers fsckle système de fichiers racine. Cela a conduit à des variations sur les points suivants:

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

Ici, j'ai répondu "non" les deux fois mais il n'y a pas de séquence de oui / non qui ne mène pas immédiatement au même résultat.

Le système de fichiers peut être monté et sur inspection occasionnelle semble correct; cela fonctionne également très bien dans l'appareil, et c'est le système de fichiers racine (en fait, il s'est avéré ne pas être très bien, voir les commentaires; tldr certains répertoires irrémédiablement corrompus).

J'avais ddla partition (8 Go) dans un fichier et j'ai essayé fsck dessus. De façon intéressante:

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)

A la suite fsckpassé propre, l'image peut être monté, et fsck -faprès cela passe aussi.

Mais le système de fichiers sur la carte à partir de laquelle l'image de copie de bloc brute a été créée a toujours le même problème - sauf que celui systemd-fsckqui a lieu pendant le démarrage enregistre le système de fichiers comme "propre". Par la suite cependant, un arrêt correct, retirer la carte et fsckréessayer à partir d'une autre boîte présente la même erreur.

Chaque fois que l'original est monté sur une autre machine, syslog note:

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

Puisque j'ai tout sauvegardé, je suis prêt à essayer quoi que ce soit ici. Je pourrais simplement oublier cela et restaurer la partition à partir de l'image apparemment fixe, mais cela ne semble pas être une solution très satisfaisante, car cela signifie que fsck a échoué cryptiquement à résoudre un problème mineur.

Je soupçonne que cela va se transformer en une question "demande de documentation officielle" concernant des choses comme les besoins recovery_flag (ou tout simplement la question "Qu'est-ce que cela signifie?"), Donc toutes les suggestions dans ce sens sont appréciées.

ext4 fsck sd-card

— boucle d'or
source

Quelque chose dans les journaux du noyau sur les erreurs de périphérique? Ce ne serait pas la première fois qu'une carte SD deviendrait soudainement en lecture seule.

— Mark Plotnick

@MarkPlotnick Non, et il est accessible en écriture. La dernière chose dans le journal d'avant le problème était le redémarrage de systemd (le périphérique est sans tête et ne répond plus après une longue période apt upgrade). Après cela, il enregistre un démarrage normal - et le systemd-fsck dit "propre" (je vais le modifier), mais essayer fsck en dehors de ce contexte échoue toujours.

— goldilocks

Votre fsck sur la copie a effacé 4 inodes, mais a corrigé le nombre d'inodes libres en le réduisant de 2453 inodes! C'est énorme. Vérifiez que l'appareil est suffisamment alimenté.

— meuh

@meuh Je remarque à chaque fois qu'il est monté sur la grande boîte que syslog fait référence à ces 4 inodes (édités ci-dessus). Certaines choses sur le fs se sont avérées être gâchées (modules de noyau mis à jour! \ O /), j'ai donc brûlé une nouvelle carte et je vais m'accrocher à l'ancienne au cas où j'aurais l'occasion de creuser davantage. Ce n'est pas exactement nouveau - une carte sans marque de classe 10, utilisée 24 heures sur 24, 7 jours sur 7, peut-être donc ... Je ne pense pas qu'il y ait moyen de vérifier qu'une carte SD est définitivement disparue , mais je suppose que ça pourrait être ça. La puissance doit être correcte mais peut être incertaine dans certaines conditions.

— goldilocks

N'est-ce pas vraiment nul quand l'outil même qui est censé résoudre votre problème ne fonctionne pas en raison de la nature du problème? Conclusion: l'outil est mauvais et doit être corrigé.

— Marc.2377

Réponses:

Je viens de rencontrer ce même problème. Après avoir débogué le problème avec le e2fsckresponsable, nous avons réalisé que la carte SD était cassée. Il acceptait les écritures sans erreur, mais il n'écrivait pas réellement les données sur la carte. La carte SD était effectivement en lecture seule.

Il semble que la carte soit entrée dans une sorte de mode de sécurité intégrée, où les données pouvaient toujours être lues, mais rien écrit.

Le e2fsckmessage unable to set superblock flagssignifie qu'il a essayé d'écrire dans le superbloc pour marquer le journal comme traité, ce qui s'est produit sans erreur, mais lorsqu'il est allé relire le superbloc, il a toujours indiqué que le journal devait être relu. En d'autres termes, les modifications écrites dans le superbloc n'ont pas été enregistrées sur le support de stockage.

La carte que j'utilise qui a ce problème est un microSD Samsung Evo 16 Go, que je mentionne juste au cas où c'est un problème commun avec ces cartes.

J'ai pu tester cela en utilisant ddpour écrire 4096 octets depuis /dev/zerosur la carte au bloc 0, puis j'ai relu à partir de la carte et au lieu d'obtenir tous les zéros comme je le devrais, j'ai toujours le superbloc ext4 inchangé d'origine.

Je suis en train de déplacer les données sur une nouvelle carte et de voir si je peux obtenir un remplacement de Samsung, qui semble offrir une garantie de 10 ans sur les cartes SD.

MISE À JOUR: Samsung a remplacé la carte de 16 Go par une carte de 32 Go dans la même série Evo, alors devinez que je ne peux pas trop me plaindre!

— Malvineous
source

"où les données pouvaient encore être lues, mais rien n'était écrit" -> Le fs était accessible en écriture.

— goldilocks

@goldilocks: Il semble que votre superbloc fs ne soit pas accessible en écriture. De plus, mes fs sont apparus accessibles en écriture grâce à la mise en cache, ce n'est qu'après démontage et remontage que j'ai remarqué que des modifications étaient perdues.

— Malvineous

Ce n'était pas une illusion en raison de la mise en cache.

— goldilocks

Je sais que c'est un vieux fil de discussion, mais je me suis dit que j'offrirais un aperçu.

Cela semble être la façon dont les cartes SD meurent d'une mort naturelle. Le nombre de cycles de lecture / écriture que les cartes SD peuvent subir est nettement inférieur à la plupart des autres supports considérés comme «lecture / écriture». Lorsque cela aura été épuisé, la carte passera en mode lecture seule, mais ne vous en informera pas. Beaucoup de choses penseront qu'elles écrivent sur la carte grâce à la mise en cache du système d'exploitation, etc., mais rien ne colle jamais.

Une excellente façon de tuer une carte SD est de la monter en tant que partition de swap ou quelque chose de très intensif en lecture / écriture. Vous seriez surpris de la rapidité avec laquelle vous pouvez tuer une carte de cette façon. J'ai constaté que l'exécution de knoppix sur une carte sd ou une clé USB ne durera qu'un mois ou deux, selon la qualité de la carte et l'intensité de l'utilisation de knoppix. (Depuis, je suis passé à l'exécution de knoppix sur un lecteur SSD USB qui a duré quelques années maintenant).

— Joe
source