Risolvere un errore del file system Btrfs di sola lettura su SUSE Linux Enterprise

Quando si tenta di salvare un file o aggiornare un servizio su SUSE Linux Enterprise Server (SLES), Linux risponde con il messaggio "File system di sola lettura". Questo messaggio può significare che il mount è stato impostato intenzionalmente in sola lettura, che è stato avviato un snapshot Snapper di sola lettura oppure che Btrfs ha rilevato un problema e ha smesso di accettare scritture per proteggere il volume. Queste cause richiedono risposte diverse. Iniziate identificando il file system e il mount coinvolti; non forzate un rimontaggio né eseguite un comando di riparazione prima di aver controllato i log del kernel e protetto i dati importanti.

Cosa significa l'errore

Btrfs è un filesystem Linux copy-on-write utilizzato di default come filesystem root di SLES in molte installazioni standard. Un sottovolume Btrfs è una parte di un filesystem che può essere montata indipendentemente; uno snapshot è una copia puntuale di un sottovolume che condivide blocchi di dati invariati. Snapper e il menu di avvio di SLES possono utilizzare gli snapshot per ripristinare il sistema dopo modifiche. L'avvio di uno snapshot monta intenzionalmente le parti incluse in modalità di sola lettura. Inoltre, Btrfs può passare alla modalità di sola lettura dopo aver rilevato determinati errori strutturali per evitare ulteriori scritture. SUSE documenta il comportamento degli snapshot nella sua guida a Snapper per SLES 15 SP7 ; il progetto Btrfs spiega che i controlli strutturali del filesystem possono impostare un volume in modalità di sola lettura per prevenire ulteriori danni nella sua documentazione relativa al tree-checker . Le etichette esatte del menu e le opzioni di ripristino disponibili possono variare a seconda del service pack di SLES e della configurazione dello storage.

Un problema di permessi è diverso. "Permesso negato" di solito indica problemi di proprietà o di controllo degli accessi; "File system di sola lettura" (spesso mostrato come EROFS) indica lo stato del file system o del sottovolume. La modifica dei permessi dei file con chmodnon renderà scrivibile un mount di sola lettura.

Prima di cambiare qualsiasi cosa

Se si tratta di un server di produzione, di un volume di database o dell'unica copia di dati importanti, contattare l'amministratore di sistema e confermare il backup prima di tentare il ripristino. Quando il sistema è ancora leggibile, copiare i file più importanti su un'unità di archiviazione separata e funzionante, se possibile senza sovraccaricare un dispositivo difettoso. Dopo un errore critico, le modifiche recenti ai metadati di Btrfs potrebbero essere memorizzate solo in memoria; uno smontaggio o un riavvio possono causare la perdita di tali modifiche non salvate. Se i log segnalano errori di I/O, dispositivi scomparsi o riavvii ripetuti, dare priorità all'integrità dell'archiviazione e alla protezione dei dati rispetto al ripristino delle scritture.

Non eseguire questa operazione btrfs check --repaircome primo passaggio di routine. Il progetto Btrfs avverte che la modalità di ripristino può causare danni e non è in grado di risolvere ogni tipo di corruzione. Non forzare ripetutamente il rimontaggio in modalità lettura/scrittura: potrebbe fallire immediatamente se il kernel ha protetto il filesystem per qualche motivo.

Passaggio 1: identificare il supporto interessato

Utilizza il percorso in cui la scrittura non è riuscita. Ad esempio, se un servizio non riesce a scrivere in /srv/app, controlla quel percorso invece di presumere che il problema sia il filesystem di root:

findmnt -T /srv/app -o TARGET,SOURCE,FSTYPE,OPTIONS

Sostituire /srv/appcon il file o la directory interessati. Controllare l'output per la sorgente Btrfs, la destinazione del mount e un'opzione roo rw. La destinazione può essere /, un mount dati separato o un sottovolume. Annotare la sorgente e la destinazione prima di continuare. Se il comando segnala un altro tipo di filesystem, i passaggi specifici di Btrfs non si applicano a quel percorso.

Controlla i messaggi del kernel dell'avvio corrente per capire perché il filesystem è diventato di sola lettura:

sudo journalctl -k -b --no-pager | grep -iE 'btrfs|I/O error|read-only|readonly'

Cerca messaggi di errore Btrfs o "sola lettura forzata", errori di checksum o di struttura ad albero, errori di I/O del dispositivo e disconnessioni del dispositivo. Una riga di log è un indizio, non una diagnosi completa. Salva i messaggi e i timestamp rilevanti prima di riavviare, perché i log possono essere utili al team di supporto hardware o di storage.

Passaggio 2: Verificare la presenza di uno snapshot intenzionale di sola lettura.

Se il server è stato avviato da uno snapshot avviabile in GRUB, i file inclusi in tale snapshot sono, per impostazione predefinita, di sola lettura. Si tratta di un ambiente di ripristino per verificare uno stato precedente del sistema; non rappresenta automaticamente il sistema ripristinato in modo permanente. Confermare la voce di avvio con l'amministratore, quindi riavviare e selezionare la normale voce SLES predefinita se l'avvio dallo snapshot è stato accidentale. SUSE documenta che l'avvio da uno snapshot monta le parti del filesystem incluse in sola lettura e descrive la procedura di rollback separata nella sua guida al ripristino di SLES 15 SP7 Snapper .

Una particolare istantanea può essere di sola lettura anche se il filesystem padre è montato in modalità lettura/scrittura. Se si sta lavorando intenzionalmente con un'istantanea, è necessario esaminarla senza modificarla:

sudo btrfs property get -t subvol /path/to/subvolume ro

Sostituire il percorso con il percorso di montaggio del sottovolume. Il risultato ro=trueconferma che la proprietà del sottovolume è di sola lettura; la documentazione di riferimento delle proprietà di Btrfs descrive questo flag. Non impostare semplicemente uno snapshot di backup gestito o ricevuto da Snapper in modalità di lettura/scrittura: lo stato di sola lettura può essere parte dei presupposti per il rollback o il backup incrementale. Utilizzare un flusso di lavoro Snapper supportato o creare un sottovolume scrivibile separato quando questo è l'obiettivo.

Passaggio 3: Esaminare la configurazione di montaggio e lo stato di archiviazione.

Se findmnti report roe i log non mostrano errori Btrfs o di I/O, esaminare la voce di montaggio corrispondente in /etc/fstab. Un montaggio potrebbe essere stato configurato deliberatamente in sola lettura per il ripristino, un'immagine dell'appliance o una policy di protezione dei dati. Modificare la configurazione solo dopo aver confermato lo stato previsto con il responsabile del servizio. Verificare inoltre se il sistema utilizza una distribuzione transazionale o di sola lettura della directory root: SLES documenta tali configurazioni e il relativo flusso di lavoro di manutenzione nella sua guida agli aggiornamenti transazionali . Se la voce è esplicitamente configurata per essere scrivibile, il dispositivo è integro e il percorso non è uno snapshot di sola lettura, un amministratore può tentare un rimontaggio temporaneo:

sudo mount -o remount,rw /mountpoint

Sostituire /mountpointcon il target esatto mostrato da findmnt. Questa operazione non diagnostica né ripara la corruzione. Se fallisce, restituisce un errore o i log del kernel mostrano problemi di archiviazione, interrompere e passare alla pianificazione del ripristino anziché riprovare con più opzioni.

Per un possibile problema di capacità, verificare l'allocazione Btrfs e lo stato del dispositivo:

sudo btrfs filesystem usage /mountpoint
sudo btrfs filesystem show /mountpoint

SUSE fa notare che i normali riepiloghi dello spazio libero su disco possono essere fuorvianti su Btrfs perché dati e metadati vengono allocati separatamente. Gli snapshot di Snapper possono anche conservare una quantità considerevole di spazio. Tuttavia, il messaggio "Spazio insufficiente sul dispositivo" non è identico a un errore di sola lettura di Btrfs; è necessario identificare il messaggio effettivamente ricevuto dall'applicazione. Non eliminare gli snapshot solo per verificare un'ipotesi. Prima di procedere, accertati del loro contenuto e segui le politiche di conservazione applicabili. Consulta la guida alla risoluzione dei problemi del file system di SLES 15 SP7 .

Passaggio 4: Decidere se il filesystem necessita di ripristino

Se nel log del kernel compaiono errori Btrfs, il dispositivo non è presente o il rimontaggio viene rifiutato, conservare i log e predisporre un backup verificato o uno snapshot a livello di storage prima di procedere con le riparazioni. Per un volume dati non root, pianificare una finestra di manutenzione e smontarlo prima di effettuare i controlli offline. Per il filesystem root, utilizzare il supporto di installazione o di ripristino di SUSE e seguire la procedura specifica per la versione di SLES e la firma dell'errore. Non tentare di indovinare il nome del dispositivo: un filesystem Btrfs può estendersi su più dispositivi, quindi stabilire prima tutti i membri e gli identificatori di mount o di dispositivo corretti.

La guida di amministrazione di SUSE SLES 15 SP7 contiene una sezione specifica per le partizioni root Btrfs che non possono essere montate. Vengono illustrate le opzioni di ripristino per questo tipo di errore di avvio. Queste istruzioni non implicano che il log di ogni filesystem di sola lettura montato debba essere cancellato. Il manuale di btrfs-rescue, sviluppato a monte, spiega che questa btrfs rescue zero-logprocedura è prevista per determinati errori di riproduzione del log durante il montaggio e può comportare la perdita delle modifiche apportate dall'ultima transazione confermata. È consigliabile utilizzarla solo quando l'errore registrato corrisponde al caso documentato e il piano di ripristino tiene conto della possibile perdita di dati.

btrfs checkPer impostazione predefinita, il programma viene eseguito in sola lettura su un filesystem non montato. Mantienilo in questo stato per la valutazione iniziale e condividi l'output con l'assistenza SUSE o con uno specialista di Btrfs. Il manuale ufficiale di btrfs-check sconsiglia esplicitamente l'utilizzo --repairsenza il parere di un utente esperto o di uno sviluppatore. Non eseguire mai un controllo offline su un filesystem montato e in fase di modifica.

Passaggio 5: Verifica il ripristino

Dopo aver corretto la causa, riavviare solo quando previsto dal piano di ripristino. Quindi, utilizzare findmnt -T /path -o TARGET,SOURCE,FSTYPE,OPTIONSnuovamente il comando e verificare che il mount desiderato sia in modalità lettura/scrittura. Controllare il log del kernel per individuare eventuali nuovi errori Btrfs o di I/O. Infine, verificare che il servizio o l'applicazione interessata possa funzionare normalmente e confermare che il backup sia ancora disponibile. Un rimontaggio riuscito da solo non dimostra che lo storage sia integro.

Se il filesystem torna in modalità di sola lettura, il dispositivo si disconnette o gli errori persistono, interrompi le scritture e inoltra il problema con i log salvati, findmntl'output, l'elenco dei dispositivi Btrfs, il livello del service pack SLES e i dettagli del controller di archiviazione. Queste prove aiutano a distinguere uno snapshot intenzionale o un'opzione di montaggio da un danno al supporto, alla connessione, al driver o al filesystem, evitando che uno stato di sola lettura protettivo si trasformi in un problema di ripristino più complesso.