fsck no fsck (no se pueden establecer marcas de superbloque)

Después de un apagado sucio en un dispositivo basado en una tarjeta SD, llevé la tarjeta SD al fscksistema de archivos raíz. Esto llevó a variaciones en lo siguiente:

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

Aquí he respondido "no" las dos veces, pero no hay una secuencia de sí / no que no conduzca inmediatamente al mismo resultado.

El sistema de archivos se puede montar y en la inspección casual parece estar bien; también funciona bien en el dispositivo, y ese es el sistema de archivos raíz (en realidad resultó no estar bien, vea los comentarios; tldr algunos directorios irremediablemente dañados).

Hice ddla partición (8 GB) a un archivo, e intenté fsck en eso. Interesantemente:

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)

Una fscklimpieza posterior pasó, la imagen se puede montar, y fsck -fdespués de eso también pasa.

Pero el sistema de archivos en la tarjeta desde la cual se creó la imagen de copia en bloque sin procesar aún tiene el mismo problema, excepto que el systemd-fsckque tiene lugar durante el arranque registra el sistema de archivos como "limpio". Posteriormente, sin embargo, un apagado correcto, sacar la tarjeta e intentar fscknuevamente desde otra casilla presenta el mismo error.

Cada vez que el original se monta en otra máquina, las notas de syslog:

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

Como tengo todo respaldado, estoy dispuesto a probar cualquier cosa aquí. Simplemente podría olvidarme de esto y volver a crear la partición de la imagen aparentemente fija, pero eso no parece una solución muy satisfactoria, ya que significa asumir que fsck falló crípticamente al resolver un problema menor.

Sospecho que esto se convertirá en una pregunta de "solicitud de documentación oficial" con respecto a cosas como necesidades recovery_flag (o simplemente la pregunta "¿Qué significa esto?"), Por lo que se agradece cualquier sugerencia en ese sentido.

ext4 fsck sd-card

— encerrada dorada
fuente

¿Hay algo en los registros del kernel sobre errores del dispositivo? Esta no sería la primera vez que una tarjeta SD de repente se convirtió en solo lectura.

— Mark Plotnick

@ MarkPlotnick No, y se puede escribir. Lo último en el registro antes del problema fue reiniciar el sistema (el dispositivo no tiene cabeza y no responde después de un largo tiempo apt upgrade). Después de eso, registra un arranque normal, y el systemd-fsck dice "limpio" (lo editaré), pero intentar fsck fuera de ese contexto todavía falla.

— Ricitos

¡Su fsck en la copia borró 4 inodes, pero arregló el recuento de inodos libres al reducirlo en 2453 inodos! Eso es enorme Compruebe que el dispositivo esté recibiendo suficiente energía.

— meuh

@meuh Me doy cuenta de que cada vez que está montado en la caja grande, syslog se refiere a esos 4 inodes (editado anteriormente). Algunas cosas en el fs resultaron estar desordenadas (¡módulos de kernel actualizados! \ O /) así que he quemado una nueva tarjeta y me quedaré con la anterior en caso de que tenga la oportunidad de profundizar más en esto. No es exactamente nuevo: una tarjeta de negociación sin marca de clase 10, en uso (liviano) las 24 horas del día, los 7 días de la semana, posiblemente durante algunos años, así que ... No creo que haya ninguna forma de verificar que una tarjeta SD esté definitivamente desactivada , pero supongo que podría ser eso. El poder debería estar bien, pero podría ser dudoso bajo ciertas condiciones.

— Ricitos

¿Realmente apesta cuando la herramienta que se supone que soluciona el problema no funciona debido a la naturaleza del problema? Conclusión: la herramienta es mala y debe repararse.

— Marc.2377

Respuestas:

Me encontré con este mismo problema. Después de depurar el problema con el e2fsckmantenedor, nos dimos cuenta de que la tarjeta SD estaba rota. Estaba aceptando escrituras sin error, pero en realidad no estaba escribiendo los datos en la tarjeta. La tarjeta SD fue efectivamente de solo lectura.

Parece que la tarjeta había entrado en una especie de modo a prueba de fallas, donde los datos aún podían leerse, pero no se escribía nada.

El e2fsckmensaje unable to set superblock flagssignifica que trató de escribir en el superbloque para marcar el diario como procesado, lo que sucedió sin error, pero cuando fue a leer el superbloque nuevamente, aún indicaba que era necesario volver a reproducir el diario. En otras palabras, los cambios escritos en el superbloque no se guardaron en el medio de almacenamiento.

La tarjeta que estoy usando que tiene este problema es una microSD Samsung Evo de 16GB, que menciono en caso de que sea un problema común con estas tarjetas.

Pude probar esto usando ddpara escribir 4096 bytes desde /dev/zerola tarjeta en el bloque 0, luego leí de la tarjeta y en lugar de obtener todos los ceros como debería, todavía obtuve el superbloque ext4 original sin cambios.

Ahora estoy en el proceso de mover los datos a una nueva tarjeta y luego ver si puedo obtener un reemplazo de Samsung, que parece ofrecer una garantía de 10 años en las tarjetas SD.

ACTUALIZACIÓN: Samsung reemplazó la tarjeta de 16 GB por una de 32 GB en la misma serie Evo, ¡así que supongo que no me puedo quejar demasiado!

— Malvinoso
fuente

"donde los datos aún podían leerse, pero no se escribía nada" -> El fs se podía escribir.

— Ricitos de Oro

@goldilocks: Sin embargo, parece que su superbloque fs puede no haber sido editable. Además, mi fs parecía escribible gracias al almacenamiento en caché, solo después de desmontar y volver a montar noté que se habían perdido los cambios.

— Malvineous

No fue una ilusión debido al almacenamiento en caché.

— Ricitos de oro

Sé que este es un hilo viejo, pero pensé que ofrecería alguna idea.

Esta parece ser la forma en que las tarjetas SD mueren de muerte natural. El número de ciclos de lectura / escritura que las tarjetas SD pueden soportar es sustancialmente menor que la mayoría de los otros medios considerados 'lectura / escritura'. Cuando eso se haya agotado, la tarjeta entrará en modo de solo lectura, pero no le informará al respecto. Muchas cosas pensarán que están escribiendo en la tarjeta gracias al almacenamiento en caché del sistema operativo, etc., pero nada se pega.

Una excelente manera de eliminar una tarjeta SD es montarla como una partición de intercambio o algo que requiera mucha lectura / escritura. Te sorprendería lo rápido que puedes matar una carta de esa manera. Descubrí que ejecutar Knoppix desde una tarjeta SD o memoria USB solo durará uno o dos meses, dependiendo de la calidad de la tarjeta y la intensidad del uso de Knoppix. (Desde entonces he cambiado a ejecutar knoppix desde una unidad SSD USB que ha durado un par de años).

— Joe
fuente