Quando SLES Btrfs passa in modalità di sola lettura: diagnosticare prima di rimontarlo

Se un filesystem Btrfs di SUSE Linux Enterprise segnala "Filesystem di sola lettura", innanzitutto verifica se è stato montato in sola lettura intenzionalmente o se è passato a tale modalità a seguito di un errore. Controlla le opzioni di montaggio, lo spazio libero e il log del kernel prima di tentare un rimontaggio. Utilizza Snapper rollback per creare uno snapshot di sistema avviabile verificato; se Btrfs ha registrato errori di I/O o di metadati, proteggi i dati e diagnostica il percorso di archiviazione prima di scrivere nuovamente sul filesystem.

1. Distinguere un mount intenzionale di sola lettura da un errore del filesystem

Sostituire /datacon il punto di montaggio interessato, oppure /per la radice.

findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /data

Nel primo comando, cerca roo rwnelle opzioni. Uno snapshot Snapper di sola lettura dovrebbe rifiutare le scritture. Anche un mount configurato con roin /etc/fstabpotrebbe essere intenzionale. Btrfs può anche passare alla modalità di sola lettura dopo gravi errori di transazione, metadati o dispositivo. In tal caso, l'esecuzione ripetuta mount -o remount,rwnon risolve la causa e potrebbe fallire immediatamente.

Se il filesystem è stato montato intenzionalmente in sola lettura, il dispositivo è integro e il log del kernel non presenta errori Btrfs o di I/O, un normale mount di dati può essere rimontato in modalità lettura/scrittura:

sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONS

Non utilizzare questo comando per il ripristino di uno snapshot di sola lettura avviato o di un filesystem di sola lettura forzato da un errore. Un rimontaggio riuscito conferma la possibilità di scrittura, non l'integrità del filesystem.

2. Verificare se la pressione dello spazio è il vero problema

Anche quando una visualizzazione di base del disco mostra anomalie, Btrfs può esaurire lo spazio allocabile, poiché l'allocazione dei dati e dei metadati viene tracciata separatamente. Verifica sia lo spazio libero ordinario che l'utilizzo di Btrfs:

df -hT /data
sudo btrfs filesystem usage -T /data

Se il sistema segnala errori No space left on devicee il log del kernel non mostra guasti del dispositivo o errori strutturali, prima di rimuovere qualsiasi elemento, verificare l'utilizzo di Snapper:

sudo snapper list

Elimina solo gli snapshot che la tua policy di conservazione ti consente di perdere, uno sudo snapper delete SNAPSHOT_IDper ogni ID selezionato. Conserva uno snapshot precedente all'aggiornamento funzionante se hai bisogno di un'opzione di ripristino; l'eliminazione degli snapshot recupera spazio ma rimuove i punti di ripristino. La pulizia potrebbe non ripristinare immediatamente lo spazio e gli snapshot non correggono gli errori di I/O. Non eseguire un bilanciamento per forzare la scrittura di un filesystem di sola lettura; questa operazione sposta i dati ed è pensata per un problema di allocazione diagnosticato su un filesystem sano e scrivibile.

3. Leggere il registro del kernel prima di scegliere una riparazione

Cerca il primo errore relativo a Btrfs, dispositivi a blocchi, controller o trasporto, non solo il messaggio finale che indica che il filesystem è diventato di sola lettura:

sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'

I messaggi relativi a letture non riuscite, mancate corrispondenze del checksum, dispositivi mancanti o errori di I/O indicano una strada diversa da una semplice roopzione di montaggio. Verificare le informazioni sullo stato del disco, del controller, del RAID/HBA, della SAN o del livello del disco virtuale e del fornitore. Correggere prima eventuali problemi hardware o di connettività instabili. Se i dati sono importanti, ridurre al minimo le scritture e concordare con un amministratore un backup o un'immagine a livello di blocco prima di tentare la riparazione del filesystem.

4. Scegliere il recupero meno rischioso che corrisponda alle prove

Su SLES, gli snapshot avviabili utilizzano la configurazione root predefinita di Snapper. La root deve essere Btrfs su un dispositivo, il boot loader deve supportarla e viene ripristinato solo il sottovolume root. Verificare l'immagine candidata prima di confermarla; se non idonea, riavviare il sistema corrente o l'ambiente di ripristino. Consultare la procedura di ripristino di Snapper per SLES 15 SP7 .

Quando sono appropriati controlli offline o una verifica

Se il filesystem non si monta o i messaggi del kernel suggeriscono un danno strutturale, avviare il sistema di ripristino SLES o un altro ambiente di ripristino appropriato, identificare il dispositivo corretto e assicurarsi che sia smontato prima di eseguire il controllo predefinito in sola lettura:

sudo btrfs check /dev/DEVICE

Utilizzare il dispositivo a blocchi Btrfs effettivo, non un segnaposto per il punto di montaggio. Un controllo può richiedere tempo e memoria e segnala anomalie strutturali; non garantisce la riparazione. Non aggiungerlo --repaircome passaggio successivo di routine. La documentazione di Btrfs avverte che la riparazione può peggiorare la situazione e dovrebbe essere eseguita solo con la guida di un esperto, dopo aver accettato il rischio per i dati. Consultare l'assistenza SUSE o uno specialista Btrfs se il controllo segnala errori o se il dispositivo presenta guasti di I/O.

Una volta che l'archiviazione è stabile e il filesystem è montato in modalità lettura/scrittura, sudo btrfs scrub start -B /dataè possibile verificare i checksum. Scrub non è uno strumento di verifica strutturale. Può riparare i danni solo da una copia ridondante funzionante; su una configurazione a copia singola, rileva gli errori ma non può ricostruire i dati persi. Consultare la documentazione di Btrfs scrub . Vedere anche la guida ai filesystem di SLES 15 SP7 di SUSE , l' articolo di SUSE sul ripristino di Btrfs e il manuale di Btrfs check .

Verifica il risultato

Dopo aver scelto il ripristino, verificare che il mount abbia le opzioni desiderate e che sia possibile eseguire una scrittura sicura:

findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-check

Per ripristinare uno snapshot di root, riavviare prima il sistema e verificare che il sistema predefinito si avvii normalmente. Quindi, esaminare il nuovo log del kernel per individuare eventuali errori ricorrenti di Btrfs o dei dispositivi. Un flag di lettura/scrittura da solo non è sufficiente a garantire il corretto funzionamento: se gli errori si ripresentano, interrompere le scritture e tornare alla diagnostica dello storage.