La manera más fácil
btrfs-zero-log /dev/sda5
Obtiene ese problema porque una transacción (escribir o eliminar) está atascada en el registro del diario y el disco no coincide.
Cómo funciona:
Entonces, cuando los datos se escriben primero, se escriben en el diario y luego en el disco (o al mismo tiempo, pero el diario solo guarda metadatos sobre la próxima escritura, no estoy seguro ... necesita más investigación sobre esa parte) ...
De todos modos, si apaga el sistema en el medio de esta escritura / eliminación o hace algo que bloquea el sistema (desmonte el USB que contiene su punto de montaje btrfs), cuando regrese, ese montaje no funcionará, fallará ( dmesg y btrfsck lo harán mostrarle los errores con más detalle) ...
Mirando dmesg verá esos mismos mensajes transid.
Verás algo como esto:
parent transid verify failed on 109973766144 wanted 1823 found 1821
Significa que btrfs quería transif 1826 (eso estaba en el diario) pero en el disco vio 1821. Entonces el disco estaba a 2 transacciones de estar sincronizado con el diario. Personalmente, arriesgaría un brtfs-zero-log aquí solo porque son solo 2 transacciones. Pero para estar 100% seguro si estos son sus únicos datos (por cierto, si tiene datos críticos, NUNCA debería tener solo 1 copia de ellos, siempre tenga una copia / copia de seguridad en otra ubicación segura; culpar a los creadores de btrfs no justifique contra la propia falta de responsabilidad de las personas de no tener una copia de seguridad: btrfs no es una solución de copia de seguridad, es un sistema de archivos; nada es una verdadera solución de copia de seguridad además de tener una copia de ella en otro lugar, ni siquiera paridad o unidades duplicadas, una verdadera copia de seguridad es sentado en algún lugar subterráneo en los Alpes mientras su copia activa está en su oficina en Texas)
parent transid verify failed on 31302336512 wanted 62455 found 62456
Aquí el diario quiere 62455 pero el disco está uno adelante en 62456, por lo que en su caso simplemente borraría el diario. El diario no se actualizó esta vez. Una vez más, te dije que era seguro, si son tus únicos datos y son megacríticos (la culpa es tuya), y primero haría las siguientes operaciones para estar seguro.
Ejecutar un btrfsck / dev / sda5 (que por cierto solo hace una comprobación de solo lectura, por lo que es completamente seguro, sus únicas opciones de btrfsck de las que debe preocuparse) también le mostrarán esos mensajes.
Pero tenga cuidado si esos datos son críticos, primero lo haría (como dijeron los otros caballeros)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
Luego cp o rsync todos sus archivos a una ubicación segura, luego, cuando sea seguro, haga el btrfs-zero-log, si es una operación exitosa, solo perdió mucho tiempo haciendo una copia de seguridad de su sistema (pero si no es exitoso, simplemente guardó su culo)
Luego, si los montajes fallaron, realice una restauración btrfs (volcado del sistema, según tengo entendido que es una operación reanudable, sin embargo, sigue pidiendo Y o y de vez en cuando, así que observe la salida)
btrfs restore /dev/sda5 /USB
Luego, cuando sea seguro (cuando se realiza la restauración de btrfs), haga el btrfs-zero-log, si es una operación exitosa, solo perdió mucho tiempo haciendo una copia de seguridad de su sistema (pero si no es exitoso, simplemente salvó su trasero)
Puedes ejecutar la pantalla primero
screen /bin/bash
btrfs restore /dev/sda5 /USB
PANTALLA NOTA LATERAL
Para separar (el comando aún se ejecutará): CONTROL-a luego escriba ": detach" sin las comillas y luego presione ENTER
Otra forma de desconectar: luego cierre la masilla o su terminal y se desconectará (el comando / restauración seguirá ejecutándose).
Para verificarlo, simplemente vuelva a la pantalla:
screen -x
screen -x se adjuntará a las sesiones, incluso si está separado, y a diferencia de -h dice, se adjuntará incluso si ya está adjunto también)
Si tiene varias pantallas, screen -x le indicará que necesita ser más específico para adjuntar a la sesión:
screen -ls
Es para listar todas las sesiones, fácil de recordar.
para ver el PID también puedes hacer esto:
ps aux | grep screen
Una vez que encuentre su PID, ejecute una pantalla como esta:
screen -x PID
Eso se adjuntará a una sesión específica. Puede tener varias sesiones / puttys adjuntas a la misma pantalla (generarán el mismo texto, puede escribir comandos en una y se reflejarán en la otra masilla)
nospace_cache?La respuesta de Peter resolvió el problema para mí, aunque no en Ubuntu. Tenía una
/homepartición btrfs'd que, por supuesto, se corrompió. El sistema no arrancaba porque estaba encendidofstab. Ingresé al modo de mantenimiento, corté la línea con esa partición y arranqué normalmente (tenía una partición ext4 de repuesto que podía usar como/home).Monté la partición manualmente con el siguiente comando:
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3y en realidad pude guardar mis datos. Aunque no tardó tanto en montarlo. Así que gracias Peter.fuente
ro = solo lectura
Este trabajo para mi
fuente
Yo tuve el mismo problema. Después de reiniciar, ya no pude montar mi partición btrfs. Sin embargo, ninguna de las soluciones mencionadas aquí podría resolverlo.
Lo que me solucionó fue actualizar el kernel de 3.10 a 3.12. Después de reiniciar, la partición btrfs podría volver a montarse.
fuente