Il modo più semplice
btrfs-zero-log /dev/sda5
Stai riscontrando questo problema perché una transazione (scrittura o eliminazione) è bloccata nel registro journal e il disco non corrisponde.
Come funziona:
Quindi, quando i dati vengono scritti per primi, vengono scritti sul journal e poi sul disco (o allo stesso tempo, ma il journal salva solo i metadati sulla scrittura in arrivo - non sono sicuro ... hanno bisogno di ulteriori ricerche su quella parte) ...
In ogni caso se si spegne il sistema nel bel mezzo di questa scrittura / cancellazione o fare qualcosa hickups il sistema (smontare l'USB che contiene il btrfs mount point), poi quando ritorna che montano non funzioneranno fallirà ( dmesg e btrfsck volontà mostrarti gli errori in modo più dettagliato) ...
Guardando dmesg vedrai quegli stessi messaggi transid.
Vedrai qualcosa del genere:
parent transid verify failed on 109973766144 wanted 1823 found 1821
Significa che btrfs voleva transif 1826 (che era sul journal) ma sul disco vide il 1821. Quindi il disco era a 2 transazioni di distanza dall'essere sincronizzato con il journal. Personalmente rischierei un brtfs-zero-log qui solo perché sono solo 2 transazioni. Ma per essere sicuri al 100% se questi sono i tuoi unici dati (tra l'altro se hai dati critici non dovresti MAI MAI averne solo 1 copia, avere sempre una copia / backup in un'altra posizione sicura - incolpare i creatori di btrfs giustificare contro la mancanza di responsabilità delle persone di non avere un backup - btrfs non è una soluzione di backup, è un filesystem - niente è una vera soluzione di backup oltre a possederne una copia altrove dove - nemmeno la parità o unità con mirroring, un vero backup è seduto da qualche parte sottoterra nelle Alpi mentre la sua copia attiva è nel tuo ufficio in Texas)
parent transid verify failed on 31302336512 wanted 62455 found 62456
Qui il diario vuole 62455 ma il disco è avanti a 62456, quindi nel tuo caso desidero semplicemente cancellare il diario. Il diario non si è aggiornato questa volta. Ancora una volta ti ho detto di essere al sicuro, se sono i tuoi unici dati e i suoi mega critici (peccato per te), e prima farei le operazioni seguenti per essere al sicuro.
L'esecuzione di un btrfsck / dev / sda5 (che tra l'altro fa solo un controllo di sola lettura, quindi è completamente sicuro, le sue uniche opzioni di btrfsck di cui devi preoccuparti) ti mostreranno anche quei messaggi.
Ma attenzione se quei dati sono critici, lo farei prima (Come hanno detto gli altri signori)
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
Quindi cp o rsincronizza tutti i tuoi file in una posizione sicura, quindi quando sei sicuro esegui btrfs-zero-log, se si tratta di un'operazione riuscita hai perso molto tempo eseguendo il backup del tuo sistema (ma se non ha successo, hai appena salvato il tuo culo)
Quindi se i montaggi falliscono esegui un ripristino btrfs (dump del sistema, come ho capito è un'operazione ripristinabile, tuttavia continua a chiedere Y o y di tanto in tanto, quindi guarda l'output)
btrfs restore /dev/sda5 /USB
Quindi quando è sicuro (quando viene eseguito il ripristino di btrfs) esegui btrfs-zero-log, se si tratta di un'operazione riuscita, hai semplicemente perso molto tempo a eseguire il backup del sistema (ma se non ha successo, hai appena salvato il culo)
È possibile eseguire prima lo schermo
screen /bin/bash
btrfs restore /dev/sda5 /USB
SCHERMATA NOTA LATERALE
Per staccare (il comando verrà comunque eseguito): CONTROL-a quindi digitare ": staccare" senza virgolette quindi premere INVIO
Un altro modo per staccare: quindi chiudere stucco o il terminale e si staccherà (il comando / ripristino continuerà comunque).
Per verificarlo, basta tornare allo schermo:
screen -x
lo schermo -x si collegherà alle sessioni, anche se distaccato, e diversamente da -h dice, si collegherà anche se è già collegato)
Se hai diverse schermate, screen -x ti dirà che devi essere più specifico per collegarti alla sessione:
screen -ls
Per l'elenco di tutte le sessioni, è facile ricordarlo.
per vedere il PID puoi anche fare questo:
ps aux | grep screen
Una volta scoperto il tuo PID, esegui la schermata in questo modo:
screen -x PID
Ciò si collegherà a una sessione specifica. Puoi avere più sessioni / stucchi attaccati allo stesso schermo (emetteranno lo stesso testo, puoi digitare i comandi in uno e saranno specchiati sull'altro stucco)
nospace_cache?