Come posso verificare la presenza di blocchi danneggiati su un volume fisico LVM?

Quando si utilizza ext4, è possibile verificare la presenza di blocchi con il comando e2fsck -c /dev/sda1 # or whatever. Ciò "inserirà nella lista nera" i blocchi aggiungendoli all'inode del blocco danneggiato.

Qual è l'equivalente di questo per un volume fisico LVM2? Il filesystem su di esso è ext4, ma presumibilmente, i blocchi danneggiati che vengono rilevati diventeranno non validi quando l'installazione LVM sottostante sposta i dati sul disco fisico.

In altre parole, come posso verificare la presenza di blocchi danneggiati da non utilizzare in LVM?

Quando si utilizza ext4, è possibile verificare la presenza di blocchi con il comando e2fsck -c /dev/sda1o altro. Ciò "inserirà nella lista nera" i blocchi aggiungendoli all'inode del blocco danneggiato.

e2fsck -cviene eseguito badblockssul disco rigido sottostante. È possibile utilizzare il badblockscomando direttamente su un volume fisico LVM (supponendo che il PV sia in realtà un disco rigido e non un altro tipo di dispositivo virtuale come un dispositivo RAID software MD), proprio come si userebbe quel comando su un disco rigido che contiene un file system ext.

Ciò non aggiungerà alcun tipo di informazioni di blocco errate al file system, ma non credo davvero che sia una caratteristica utile del file system; il disco rigido dovrebbe gestire blocchi danneggiati.

Anche meglio che badblockseseguire un autotest SMART sul disco (sostituire /dev/sdXcon il nome del dispositivo del disco rigido):

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

Il test impiegherà alcune ore (ti dirà esattamente per quanto tempo). Al termine, è possibile eseguire una query sul risultato con smartctl -a, cercare il registro di auto-test. Se viene visualizzato il messaggio "Completato correttamente", il disco rigido va bene.

In altre parole, come posso verificare la presenza di blocchi danneggiati da non utilizzare in LVM?

Come ho detto, il disco rigido stesso garantirà che non utilizzi i blocchi danneggiati e trasferirà anche i dati da quei blocchi; non è qualcosa che il file system o LV deve fare. D'altra parte, quando il tuo disco rigido ha più di pochi blocchi danneggiati, non vuoi qualcosa che li trasferisca, ma vuoi sostituire l'intero disco rigido perché non funziona.

Sono abbastanza sicuro che LVM non gestisca blocchi danneggiati; prevede l'archiviazione sottostante a. E la maggior parte, se non tutti, i moderni dischi rigidi lo fanno. Potrebbe essere necessario eseguire una scrittura nel settore, ma il disco dovrebbe rimapparlo. (Potrebbe essere necessario eseguire prima una scansione di superficie offline, ad esempio con smartctl /dev/sda -t offline).

Detto questo, LVM in realtà non sposta i dati se non lo chiedi, ad es pvmove. Quindi puoi usare la funzione ext4 badblocks; dovrai solo ricontrollare i blocchi danneggiati se eseguito pvmove. Nessuna operazione comune (come lvextend) sposta i dati.

Extend non sposta i dati perché LVM mantiene una mappa che dice "le estensioni logiche 0–99 sono estensioni fisiche 200–299", e quindi quando le estendi, aggiunge semplicemente "le estensioni logiche 100–199 sono estensioni fisiche 100–199". O anche "le estensioni logiche 100–149 sono estensioni fisiche 50–99; le estensioni logiche 150–199 sono estensioni fisiche 140–189". A LVM non importa che le estensioni fisiche non siano in ordine o contigue.

pvckpuò controllare i metadati LVM, dopo che la coerenza è il lavoro del filesystem. LVM riguarda solo la gestione del volume, quindi non è necessario preoccuparsi se lo spazio che costituisce una determinata estensione è negativo poiché il software di livello superiore rileva tali problemi. I metadati LVM occupano comunque solo il primo (facoltativamente anche l'ultimo settore) del volume fisico.

Se solo il primo e l'ultimo settore di un fotovoltaico abbastanza grande (come quello che vedresti in produzione) falliscono simultaneamente, in pratica hai la più piccola fortuna al mondo dal momento che è così improbabile dal punto di vista astronomico. Altrimenti, se l'amministratore sa che più settori del disco si sono guastati, la maggior parte delle persone sta bene semplicemente archiviando cose come questa in "disco rigido permanentemente guasto e deve essere sostituito".

Se pvckrestituisce un errore, puoi verificare se è stato eseguito il backup dei metadati LVM da /etc/lvmqualche parte. In tal caso, è possibile pvcreatespecificare la copia di backup in--restorefile

Sintassi:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Esempio:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

Se il ripristino non funziona (ad esempio, se il primo settore è danneggiato) puoi ripetere quanto sopra, ma impostare --metadatacopies 2(o potresti semplicemente andare a farlo) che tenterà di scrivere i metadati sul primo e ultimi settori sul fotovoltaico. Quando pvscanfa la sua cosa all'avvio controllerà entrambi i posti e se trova i metadati li verificherà rispetto a un checksum. Se il checksum ha esito negativo sul primo settore ma ha esito positivo sull'ultimo settore, verrà visualizzato un messaggio di errore non irreversibile.

Un po 'di manuale e una seccatura, ma ancora una volta questo è uno dei motivi per cui le persone sono entusiaste di ottenere un redux di gestione del volume con BTRFS. Il più delle volte non è un grosso problema per i motivi menzionati da Derobert e perché le persone che hanno assolutamente bisogno di garantire la continuità dei dati di solito fanno RAID e hanno una strategia di backup.