Che cos'è lvmetad e perché dovrei volerlo o averne bisogno?

Ho un server Gentoo con LVM in esecuzione su un array RAID che utilizzo da diversi anni. Recentemente ho aggiornato LVM alla 2.02.109 (non ricordare quale versione era prima) e ho ricevuto un messaggio durante l'aggiornamento:

* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.

Capisco che posso abilitarla impostando use_lvmetad = 1in /etc/lvm/lvm.conf.

Ma perché dovrei aver bisogno di una tale funzionalità? La mia comprensione è che funziona con le regole udev per mantenere lo stato LVM in una cache in modo che gli strumenti LVM non debbano scansionare i volumi per ottenere tali informazioni. È solo che il mio piccolo array non può beneficiare di questo tipo di funzionalità? In quali circostanze potrei volere / aver bisogno di usarlo?

Descrizione

Dalla pagina man di lvmetad :

lvmetad è un demone di memorizzazione nella cache dei metadati per LVM. Il daemon riceve notifiche dalle regole udev (che devono essere installate affinché LVM funzioni correttamente quando è in uso lvmetad). Tramite queste notifiche, lvmetad ha un'immagine aggiornata e coerente dei gruppi di volumi disponibili nel sistema. Per impostazione predefinita, lvmetad, anche se in esecuzione, non è utilizzato da LVM. Vedi lvm.conf (5).

Guardare un po 'più da vicino merita un'altra definizione. Wikipedia afferma:

Un file system di journaling è un file system che tiene traccia delle modifiche che verranno apportate in un journal (di solito un registro circolare in un'area dedicata del file system) prima di eseguirne il commit nel file system principale. In caso di arresto anomalo del sistema o interruzione dell'alimentazione, tali file system sono più veloci da riportare online e hanno meno probabilità di essere danneggiati.

Ragionamento

Non entrerò in una spiegazione dettagliata di LVM, poiché l'OP comprende già i vantaggi. Come tale, spiegherò solo perché è stato aggiunto il journaling. Le versioni precedenti di LVM non avevano un demone journaling, il che significa che se il sistema si arrestava in modo anomalo, l'unico journal che poteva essere utilizzato era sul volume fisico (disco rigido). Ciò crea un problema quando il volume logico si estende su più estensioni su gruppi di volumi logici che si estendono su più volumi fisici.

Se esiste una mezza transazione del journal su un volume fisico e l'altra metà esiste su un altro volume fisico, il journal transazionale non può eseguire il commit delle modifiche su entrambi i volumi fisici, poiché i volumi fisici non comprendono che fanno parte di un gruppo di volumi , poiché la transazione il registro esiste solo nel volume fisico.

È qui che entra in gioco il nuovo demone. Ora invece di un registro giornale per ogni volume fisico, LVM può creare un registro giornale e crearne una sezione nel gruppo di volumi, che è riservata esclusivamente al journal. Successivamente, è possibile trovare e riprodurre l'intero registro delle transazioni a livello di gruppo di volumi.

Da questo link :

Normalmente, ogni comando LVM emette una scansione del disco per trovare tutti i volumi fisici rilevanti e leggere i metadati del gruppo di volumi. Tuttavia, se il demone dei metadati è in esecuzione e abilitato, questa scansione costosa può essere ignorata ... Ciò può salvare una quantità significativa di I / O e ridurre il tempo necessario per completare le operazioni LVM, in particolare su sistemi con molti dischi.

Quindi lo eseguiresti per migliorare le prestazioni della gestione LVM e le operazioni di stato, a scapito delle prestazioni di avvio e una maggiore complessità. Il livello di aumento delle prestazioni è maggiore quando vi sono più dischi nel sistema.