¿Cómo arreglo btrfs? [cerrado]

He rastreado listas de correo y finalmente terminé en la btrfspágina de Ubuntu , y me queda la sensación de que btrfs todavía no tiene una utilidad de reparación completa (como se indica en su página de inicio ). Aunque hace meses estaba programado para ser el predeterminado para Linux de Oracle y está incluido en muchas distribuciones.

Entonces, en lugar de eso, ¿hay alguna guía de solución de problemas en algún lugar sobre cómo solucionarlo btrfs?

De lo contrario, ¿la copia de mis copias de seguridad en la parte superior de mi FS solucionará las cosas? (¿Al eliminar instantáneas si es necesario para el espacio? ¿O para eliminar la corrupción?) ¿Debería tratar de volver a una instantánea anterior y luego restaurar los archivos faltantes de la copia de seguridad? ¿O restaurar los archivos faltantes de mis instantáneas @ y @home?

Nota : Esta es una pregunta general. He omitido deliberadamente mis problemas exactos de FS (por el momento); Quiero encontrar un flujo de trabajo general / canónico y una guía de solución de problemas.

(Ok, ok, aquí hay más detalles;)) :

Me apagué durante un apagado bloqueado y, por lo tanto, se me presentó la inestabilidad del sistema. El sistema se iniciará y ejecutará durante un cierto tiempo hasta que escriba suficientes datos y se congele. La última vez que abrí Thunderbird. Estos requieren más reinicios duros y presumiblemente más corrupción. sudo btrfsck /dev/sda1oscila entre unos pocos errores, a menudo por primera vez en el formulario

root 338 inode 7861227 errors 1000
root 338 inode 7904568 errors 1000
root 338 inode 7955174 errors 400
found 46242054144 bytes used err is 1
total csum bytes: 43112400
total tree bytes: 2074640384
total fs tree bytes: 1889853440
btree space waste bytes: 547680627
file data blocks allocated: 110756974592
 referenced 68393684992
Btrfs Btrfs v0.19

oooo, ahora es getty realmente afrutado (solo esperaba verlo parent transid verify failedaquí ...)

parent transid verify failed on 14266105856 wanted 464223 found 464221
parent transid verify failed on 14266105856 wanted 464223 found 464221
Extent back ref already exists for 14261530624 parent 0 root 256 
leaf parent key incorrect 14261751808
bad block 14261751808
Extent back ref already exists for 66455355392 parent 0 root 2 
Extent back ref already exists for 66455257088 parent 0 root 2 
Extent back ref already exists for 14257274880 parent 0 root 2 
block 14262571008 rec extent_item_refs 2, passed 2
block 14262575104 rec extent_item_refs 1, passed 1
block 14262579200 rec extent_item_refs 1, passed 1
Extent back ref already exists for 14262579200 parent 0 root 257 
leaf 14263906304 items 50 free space 132 generation 464224 owner 2
fs uuid 7d049403-cf6e-4b52-a624-32051e1f5b2a
chunk uuid be6f8f93-320c-4465-85d6-f53907698c32
item 0 key (14263341056 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332576 1 0) level 0
    tree block backref root 257
item 1 key (14263345152 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332586 c 8332543) level 0
    tree block backref root 257
failed to find block number 14263525376

(Todo muy resumido, por supuesto; nunca quise abrumarte con estos detalles :))

Y ahora mi ejecución final me deja con lo familiar:

parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464223
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed.

, incluido el error aleatorio opcional al final. Oh feliz alegría. Tenga en cuenta que estos verify failedcambian a medida que los datos se escriben en la unidad.

Otro error al azar:

btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.

Para ayudar con la respuesta:

la verificación de transid del padre falló el 14265458688 quería 464230 encontrado 464221

Se puede arreglar con:

$ btrfs-zero-log DEVICE

NOTA: los datos pueden perderse! Primero intente y monte con:

$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT

Si no puede montar datos como dice "fs malo":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Aquí hay un correo electrónico real, aunque difícil de seguir, que envié para aclarar su solución. Espero que puedas entender esta explicación críptica:

extracto de correo electrónico

Re: Pregunta: ¿Cómo puedo recuperar esta partición? (no se puede encontrar $ hugenum len 4096 lógico)

Hugo Mills carfax.org.uk> escribe:

El lunes 26 de agosto de 2013 a las 01:10:54 p.m.-0600, Chris Murphy escribió:

El 26 de agosto de 2013, a las 11:41 a.m., Nick Lee nickle.es> escribió:

Hubo una discusión sobre IRC hace unos días que el problema con el bloco de la raíz del árbol probablemente era el resultado de un problema con el disco en sí, o el árbol de fragmentos / asignaciones lógicas. Ejecuté el fragmento de recuperación, revisé los errores que encontró y presioné escribir. (Si fallaba, iba a ejecutar algo fotorec, pérdida de organización como efecto secundario).

Puedo escribir algo más claro después de que mi vuelo aterrice mañana si quieres.

Tengo curiosidad por saber cuándo usar varias técnicas: -o recovery, btrfsck, chunk-recovery, zero log.

Supongamos que no tiene una falla en el dispositivo físico (que es un conjunto diferente de herramientas: mount -odegraded, btrfs dev del missing).

Lo primero que debe hacer es tomar una imagen btrfs -c9 -t4 del sistema de archivos y conservar una copia de la salida para mostrar josef. :)

Luego comience con -orecovery y -oro, recuperación para casi cualquier cosa.

Si fallan, busque en dmesg los errores relacionados con el árbol de registro; si está dañado y no se puede leer (o causa un bloqueo), use btrfs-zero-log.

Si hay problemas con el árbol de fragmentos (el único que he visto recientemente fue informar algo como "no se puede asignar la dirección"), entonces puede ser útil utilizar la recuperación de fragmentos.

Después de eso, btrfsck es probablemente lo siguiente que debe intentar. Si las opciones -s1, -s2, -s3 tienen éxito, entonces btrfs-select-super ayudará al reemplazar el superbloque por uno que funcione. Si eso no va a ser útil, recurra a btrfsck --repair.

Finalmente, btrfsck --repair --init-extension-tree puede ser necesario si hay un árbol de extensión dañado. Finalmente, si tiene corrupción en las sumas de verificación, hay --init-csum-tree.

Hugo