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.