Pericoli e avvertimenti di LVM

Soluzione 1:

Riepilogo

Rischi dell'utilizzo di LVM:

• Vulnerabile a scrivere problemi di memorizzazione nella cache con hypervisor SSD o VM
• Più difficile recuperare i dati a causa di strutture su disco più complesse
• Più difficile ridimensionare correttamente i filesystem
• Le istantanee sono difficili da usare, lente e piene di bug
• Richiede una certa abilità per configurare correttamente dati questi problemi

I primi due problemi di LVM si combinano:se la cache di scrittura non funziona correttamente e si verifica un'interruzione dell'alimentazione (ad es. PSU o UPS non funziona), potrebbe essere necessario eseguire il ripristino dal backup, il che significa tempi di inattività significativi. Uno dei motivi principali per l'utilizzo di LVM è il tempo di attività più elevato (quando si aggiungono dischi, si ridimensionano i file system, ecc.), ma è importante che l'impostazione della cache di scrittura sia corretta per evitare che LVM riduca effettivamente il tempo di attività.

-- Aggiornamento di dicembre 2019:aggiornamento minore su btrfs e ZFS come alternative agli snapshot LVM

Mitigare i rischi

LVM può ancora funzionare bene se:

• Ottieni la configurazione della cache in scrittura direttamente in hypervisor, kernel e SSD
• Evita gli snapshot LVM
• Usa le versioni recenti di LVM per ridimensionare i filesystem
• Avere buoni backup

Dettagli

Ho studiato questo un bel po 'in passato dopo aver riscontrato una perdita di dati associata a LVM. I principali rischi e problemi di LVM di cui sono a conoscenza sono:

Vulnerabile alla cache in scrittura del disco rigido a causa di hypervisor VM, cache del disco o vecchi kernel Linux , e rende più difficile il recupero dei dati a causa di strutture su disco più complesse - vedi sotto per i dettagli. Ho visto che configurazioni complete di LVM su diversi dischi sono state danneggiate senza alcuna possibilità di ripristino e la cache in scrittura di LVM e disco rigido è una combinazione pericolosa.

• Caching in scrittura e riordinamento in scrittura dal disco rigido è importante per ottenere buone prestazioni, ma può non riuscire a scaricare correttamente i blocchi sul disco a causa di hypervisor VM, caching in scrittura del disco rigido, vecchi kernel Linux e così via.
• Le barriere di scrittura indicano che il kernel garantisce che completerà determinate scritture su disco prima della scrittura su disco "barriera", per garantire che i filesystem e il RAID possano essere ripristinati in caso di improvvisa perdita di alimentazione o crash. Tali barriere possono utilizzare un'operazione FUA (Force Unit Access) per scrivere immediatamente determinati blocchi sul disco, che è più efficiente di uno svuotamento completo della cache. Le barriere possono essere combinate con un'efficiente accodamento di comandi con tag/nativo (che invia più richieste di I/O su disco contemporaneamente) per consentire al disco rigido di eseguire un riordino di scrittura intelligente senza aumentare il rischio di perdita di dati.
• hypervisor VM può avere problemi simili:l'esecuzione di LVM in un guest Linux su un hypervisor VM come VMware, Xen, KVM, Hyper-V o VirtualBox può creare problemi simili a un kernel senza barriere di scrittura, a causa della memorizzazione nella cache e del riordino della scrittura . Controlla attentamente la documentazione dell'hypervisor per un'opzione "flush to disk" o write-through cache (presente in KVM, VMware, Xen, VirtualBox e altri) e testala con la tua configurazione. Alcuni hypervisor come VirtualBox hanno un'impostazione predefinita che ignora qualsiasi scaricamento del disco da parte del guest.
• I server aziendali con LVM dovrebbero sempre utilizzare un controller RAID alimentato a batteria e disabilitare la cache di scrittura del disco rigido (il controller ha una cache di scrittura con batteria tampone che è veloce e sicura) - vedi questo commento dell'autore di questa voce delle FAQ su XFS. Potrebbe anche essere sicuro disattivare le barriere di scrittura nel kernel, ma si consiglia di testare.
• Se non si dispone di un controller RAID con batteria tampone, la disabilitazione della cache in scrittura del disco rigido rallenterà notevolmente le scritture ma renderà LVM sicuro. Dovresti anche usare l'equivalente di data=ordered di ext3 opzione (o data=journal per maggiore sicurezza), più barrier=1 per garantire che la memorizzazione nella cache del kernel non influisca sull'integrità. (Oppure usa ext4 che abilita le barriere per impostazione predefinita.) Questa è l'opzione più semplice e fornisce una buona integrità dei dati a scapito delle prestazioni. (Linux ha cambiato l'opzione ext3 predefinita nella più pericolosa data=writeback tempo fa, quindi non fare affidamento sulle impostazioni predefinite per FS.)
• Per disabilitare la cache in scrittura del disco rigido :aggiungi hdparm -q -W0 /dev/sdX per tutte le unità in /etc/rc.local (per SATA) o utilizzare sdparm per SCSI/SAS. Tuttavia, in base a questa voce nelle FAQ XFS (che è molto utile su questo argomento), un'unità SATA potrebbe dimenticare questa impostazione dopo il ripristino di un errore dell'unità, quindi dovresti usare SCSI/SAS o, se devi usare SATA, inserisci il comando hdparm in un cron job eseguito ogni minuto circa.
• Per mantenere abilitata la cache in scrittura su SSD/disco rigido per prestazioni migliori:questa è un'area complessa - vedi la sezione sotto.
• Se utilizzi unità con formattazione avanzata ad esempio settori fisici da 4 KB, vedi sotto:la disabilitazione della cache in scrittura potrebbe avere altri problemi.
• UPS è fondamentale sia per le aziende che per SOHO, ma non abbastanza per rendere LVM sicuro:tutto ciò che causa un arresto anomalo o una perdita di alimentazione (ad es. guasto dell'UPS, guasto dell'alimentatore o esaurimento della batteria del laptop) può causare la perdita di dati nelle cache del disco rigido.
• Kernel Linux molto vecchi (2.6.x dal 2009) :C'è un supporto incompleto della barriera di scrittura nelle versioni del kernel molto vecchie, 2.6.32 e precedenti (2.6.31 ha un certo supporto, mentre 2.6.33 funziona per tutti i tipi di destinazione del dispositivo) - RHEL 6 utilizza 2.6.32 con molte patch. Se questi vecchi kernel 2.6 non sono corretti per questi problemi, una grande quantità di metadati FS (inclusi i journal) potrebbe andare persa a causa di un arresto anomalo che lascia i dati nei buffer di scrittura dei dischi rigidi (diciamo 32 MB per unità per unità SATA comuni). La perdita di 32 MB dei metadati FS e dei dati del journal scritti più di recente, che il kernel ritiene siano già su disco, di solito significa molta corruzione di FS e quindi perdita di dati.
• Riepilogo: è necessario prestare attenzione al file system, al RAID, all'hypervisor VM e alla configurazione del disco rigido/SSD utilizzati con LVM. È necessario disporre di backup molto validi se si utilizza LVM e assicurarsi di eseguire in modo specifico il backup dei metadati LVM, dell'impostazione della partizione fisica, dell'MBR e dei settori di avvio del volume. È inoltre consigliabile utilizzare unità SCSI/SAS poiché è meno probabile che mentiscano su come scrivono la memorizzazione nella cache:è necessaria maggiore attenzione per utilizzare le unità SATA.

Mantenere abilitata la cache in scrittura per le prestazioni (e far fronte a pulsioni menzognere)

Un'opzione più complessa ma performante è quella di mantenere abilitata la cache di scrittura SSD/disco rigido e fare affidamento sulle barriere di scrittura del kernel che funzionano con LVM sul kernel 2.6.33+ (ricontrolla cercando i messaggi di "barriera" nei log).

È inoltre necessario assicurarsi che la configurazione RAID, la configurazione dell'hypervisor VM e il filesystem utilizzino barriere di scrittura (ovvero richiedono che l'unità scarichi le scritture in sospeso prima e dopo le scritture di metadati/journal chiave). XFS usa le barriere per impostazione predefinita, ma ext3 no, quindi con ext3 dovresti usare barrier=1 nelle opzioni di montaggio e usa ancora data=ordered o data=journal come sopra.

• Purtroppo, alcuni dischi rigidi e SSD mentono sul fatto di aver davvero svuotato la cache al disco (in particolare le unità più vecchie, ma incluse alcune unità SATA e alcuni SSD aziendali) - maggiori dettagli qui. C'è un ottimo riassunto da uno sviluppatore XFS.
• C'è un semplice strumento di test per le unità ingannevoli (script Perl), oppure guarda questo background con un altro strumento di test per il riordino della scrittura come risultato della cache dell'unità. Questa risposta copriva test simili su unità SATA che hanno scoperto un problema di barriera di scrittura nel RAID software:questi test esercitano effettivamente l'intero stack di archiviazione.
• Le unità SATA più recenti che supportano Native Command Queuing (NCQ) potrebbero avere meno probabilità di mentire o forse funzionano bene senza cache in scrittura a causa di NCQ e pochissime unità non possono disabilitare la cache in scrittura.
• Le unità SCSI/SAS sono generalmente OK in quanto non hanno bisogno di cache in scrittura per funzionare bene (tramite SCSI Tagged Command Queuing, simile all'NCQ di SATA).
• Se i tuoi dischi rigidi o SSD mentono sullo svuotamento della cache su disco, non puoi davvero fare affidamento sulle barriere di scrittura e devi disabilitare la cache di scrittura. Questo è un problema per tutti i file system, i database, i gestori di volume e il software RAID, non solo per LVM.

SSD sono problematici perché l'uso della cache di scrittura è fondamentale per la durata dell'SSD. È meglio utilizzare un SSD dotato di un supercondensatore (per abilitare lo svuotamento della cache in caso di interruzione dell'alimentazione e quindi consentire il write-back e non il write-through della cache).

• La maggior parte degli SSD aziendali dovrebbe essere OK sul controllo della cache di scrittura e alcuni includono supercondensatori.
• Alcuni SSD più economici hanno problemi che non possono essere risolti con la configurazione della cache di scrittura:la mailing list del progetto PostgreSQL e la pagina wiki Reliable Writes sono buone fonti di informazioni. Gli SSD consumer possono avere gravi problemi di cache in scrittura che causano la perdita di dati e non includono supercondensatori, quindi sono vulnerabili alle interruzioni di corrente che causano il danneggiamento.

Formato avanzato configurazione dell'unità:cache in scrittura, allineamento, RAID, GPT

• Con le unità Advanced Format più recenti che utilizzano settori fisici da 4 KiB, potrebbe essere importante mantenere abilitata la memorizzazione nella cache di scrittura dell'unità, poiché la maggior parte di tali unità attualmente emula settori logici da 512 byte ("emulazione 512"), e alcune affermano addirittura di avere 512 byte -byte di settori fisici utilizzando in realtà 4 KiB.
• La disattivazione della cache di scrittura di un'unità Advanced Format può causare un notevole impatto sulle prestazioni se l'applicazione/kernel sta eseguendo scritture da 512 byte, poiché tali unità si basano sulla cache per accumulare 8 scritture da 512 byte prima di eseguire una singola Scrittura fisica da 4 KiB. Si consiglia di eseguire test per confermare qualsiasi impatto se si disabilita la cache.
• L'allineamento dei LV su un limite di 4 KiB è importante per le prestazioni, ma dovrebbe avvenire automaticamente fintanto che le partizioni sottostanti per i PV sono allineate, poiché le estensioni fisiche LVM (PE) sono 4 MiB per impostazione predefinita. RAID deve essere considerato qui - questa pagina di configurazione di LVM e software RAID suggerisce di mettere il superblocco RAID alla fine del volume e (se necessario) di utilizzare un'opzione su pvcreate per allineare i PV. Questo thread dell'elenco e-mail di LVM indica il lavoro svolto nei kernel durante il 2011 e il problema delle scritture di blocchi parziali quando si mescolano dischi con settori da 512 byte e 4 KiB in un singolo LV.
• Il partizionamento GPT con Advanced Format richiede attenzione, in particolare per i dischi boot+root, per garantire che la prima partizione LVM (PV) inizi su un limite di 4 KiB.

Più difficile recuperare i dati a causa di strutture su disco più complesse :

• Qualsiasi ripristino dei dati LVM richiesto dopo un arresto anomalo o un'interruzione dell'alimentazione (a causa di una memorizzazione nella cache di scrittura errata) è nella migliore delle ipotesi un processo manuale, poiché apparentemente non esistono strumenti adatti. LVM è bravo a eseguire il backup dei suoi metadati in /etc/lvm , che può aiutare a ripristinare la struttura di base di LV, VG e PV, ma non aiuterà con i metadati del file system persi.
• Quindi è probabile che sia necessario un ripristino completo dal backup. Ciò comporta tempi di inattività molto più lunghi rispetto a un rapido fsck basato su journal quando non si utilizza LVM e i dati scritti dall'ultimo backup andranno persi.
• TestDisk, ext3grep, ext3undel e altri strumenti possono ripristinare partizioni e file da dischi non LVM ma non supportano direttamente il ripristino dei dati LVM. TestDisk può scoprire che una partizione fisica persa contiene un PV LVM, ma nessuno di questi strumenti comprende i volumi logici LVM. Strumenti di intaglio dei file come PhotoRec e molti altri funzionerebbero poiché aggirano il filesystem per riassemblare i file dai blocchi di dati, ma questo è un approccio di basso livello e di ultima istanza per dati preziosi e funziona meno bene con i file frammentati. /li>
• Il ripristino manuale di LVM è possibile in alcuni casi, ma è complesso e richiede molto tempo:guarda questo esempio e questo, questo e questo per sapere come eseguire il ripristino.

Più difficile ridimensionare correttamente i filesystem - il facile ridimensionamento del filesystem è spesso dato come vantaggio di LVM, ma è necessario eseguire una mezza dozzina di comandi shell per ridimensionare un FS basato su LVM - questo può essere fatto con l'intero server ancora attivo, e in alcuni casi con il FS montato, ma non rischierei mai quest'ultimo senza backup aggiornati e utilizzando comandi pre-testati su un server equivalente (ad es. clone di ripristino di emergenza del server di produzione).

• Aggiornamento: Versioni più recenti di lvextend supporta il -r (--resizefs ) opzione - se disponibile, è un modo più sicuro e veloce per ridimensionare il LV e il filesystem, in particolare se stai riducendo il FS, e puoi saltare questa sezione.

• La maggior parte delle guide al ridimensionamento dei FS basati su LVM non tiene conto del fatto che il FS deve essere un po' più piccolo della dimensione del LV:spiegazione dettagliata qui. Quando si riduce un filesystem, sarà necessario specificare la nuova dimensione nello strumento di ridimensionamento di FS, ad es. resize2fs per ext3 e a lvextend o lvreduce . Senza molta attenzione, le dimensioni potrebbero essere leggermente diverse a causa della differenza tra 1 GB (10^9) e 1 GiB (2^30) o del modo in cui i vari strumenti arrotondano le dimensioni per eccesso o per difetto.

• Se non esegui i calcoli esattamente nel modo giusto (o usi alcuni passaggi extra oltre a quelli più ovvi), potresti ritrovarti con un FS troppo grande per il LV. Tutto sembrerà a posto per mesi o anni, fino a quando non riempirai completamente il FS, a quel punto otterrai un grave danneggiamento e, a meno che tu non sia a conoscenza di questo problema, è difficile scoprire perché, poiché a quel punto potresti anche avere veri errori del disco che annebbiano la situazione. (È possibile che questo problema riguardi solo la riduzione delle dimensioni dei filesystem, tuttavia è chiaro che il ridimensionamento dei filesystem in entrambe le direzioni aumenta il rischio di perdita di dati, probabilmente a causa di un errore dell'utente.)

• Sembra che la dimensione LV dovrebbe essere maggiore della dimensione FS di 2 volte la dimensione dell'estensione fisica (PE) di LVM, ma controlla il link sopra per i dettagli poiché la fonte per questo non è autorevole. Spesso è sufficiente consentire 8 MiB, ma potrebbe essere meglio consentirne di più, ad es. 100 MiB o 1 GiB, giusto per essere sicuri. Per verificare la dimensione del PE e le dimensioni del volume logico + FS, utilizzando 4 KiB =blocchi da 4096 byte:

  Mostra la dimensione PE in KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  Dimensione di tutti i LV:
  lvs --units 4096b
  
  Dimensione di (ext3) FS, presuppone una dimensione di blocco di 4 KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Al contrario, una configurazione non LVM rende il ridimensionamento di FS molto affidabile e facile:esegui Gparted e ridimensiona gli FS richiesti, quindi farà tutto per te. Sui server, puoi usare parted dalla shell.

• Spesso è meglio usare Gparted Live CD o Parted Magic, poiché questi hanno un Gparted e un kernel recenti e spesso più privi di bug rispetto alla versione distro:una volta ho perso un intero FS a causa del Gparted della distribuzione che non aggiornava correttamente le partizioni in esecuzione nocciolo. Se usi Gparted della distribuzione, assicurati di riavviare subito dopo aver cambiato le partizioni in modo che la vista del kernel sia corretta.

Le istantanee sono difficili da usare, lente e piene di bug - se l'istantanea esaurisce lo spazio pre-allocato, viene automaticamente eliminata. Ogni snapshot di un dato LV è un delta rispetto a quel LV (non rispetto agli snapshot precedenti) che può richiedere molto spazio durante l'istantanea di filesystem con attività di scrittura significative (ogni snapshot è più grande del precedente). È sicuro creare uno snapshot LV delle stesse dimensioni del LV originale, poiché lo snapshot non esaurirà mai lo spazio libero.

Le istantanee possono anche essere molto lente (ovvero da 3 a 6 volte più lente che senza LVM per questi test MySQL) - vedi questa risposta che copre vari problemi di istantanee. La lentezza è in parte dovuta al fatto che gli snapshot richiedono molte scritture sincrone.

Le istantanee hanno avuto alcuni bug significativi, ad es. in alcuni casi possono rendere l'avvio molto lento o causare il fallimento completo dell'avvio (poiché il kernel può andare in timeout in attesa del root FS quando si tratta di un'istantanea LVM [risolto in Debian initramfs-tools aggiornamento, marzo 2015]).

• Tuttavia, molti bug di snapshot race condition sono stati apparentemente corretti entro il 2015.
• LVM senza istantanee generalmente sembra abbastanza ben debuggato, forse perché le istantanee non vengono utilizzate tanto quanto le funzionalità principali.

Alternative all'istantanea - filesystem e hypervisor VM

Istantanee VM/cloud:

• Se utilizzi un hypervisor VM o un provider cloud IaaS (ad es. VMware, VirtualBox o Amazon EC2/EBS), i loro snapshot sono spesso un'alternativa molto migliore agli snapshot LVM. Puoi facilmente scattare uno snapshot a scopo di backup (ma considera di congelare FS prima di farlo).

Istantanee del filesystem:

• le istantanee a livello di filesystem con ZFS o btrfs sono facili da usare e generalmente migliori di LVM, se sei su bare metal (ma ZFS sembra molto più maturo, solo più problemi da installare):

• ZFS:ora c'è un'implementazione del kernel ZFS, che è in uso da alcuni anni, e sembra che ZFS stia guadagnando adozione. Ubuntu ora ha ZFS come opzione "pronta all'uso", incluso ZFS sperimentale su root in 19.10.

• btrfs:ancora non pronto per l'uso in produzione (anche su openSUSE che lo fornisce di default e ha un team dedicato a btrfs), mentre RHEL ha smesso di supportarlo). btrfs ora ha uno strumento fsck (FAQ), ma le FAQ ti consigliano di consultare uno sviluppatore se hai bisogno di fsck un filesystem rotto.

Snapshot per backup online e fsck

Le istantanee possono essere utilizzate per fornire una fonte coerente per i backup, purché si presti attenzione allo spazio allocato (idealmente l'istantanea ha le stesse dimensioni del LV di cui si esegue il backup). L'eccellente rsnapshot (dalla 1.3.1) gestisce anche la creazione/cancellazione di istantanee LVM per te - guarda questo HOWTO su rsnapshot usando LVM. Tuttavia, tieni presente i problemi generali con gli snapshot e che uno snapshot non deve essere considerato un backup in sé.

Puoi anche utilizzare gli snapshot LVM per eseguire un fsck online:snapshot LV e fsck lo snapshot, pur utilizzando il principale FS non snapshot - descritto qui - tuttavia, non è del tutto semplice quindi è meglio utilizzare e2croncheck come descritto da Ted Ts 'o, manutentore di ext3.

Dovresti "congelare" temporaneamente il filesystem durante l'acquisizione dell'istantanea:alcuni filesystem come ext3 e XFS lo faranno automaticamente quando LVM crea l'istantanea.

Conclusioni

Nonostante tutto ciò, utilizzo ancora LVM su alcuni sistemi, ma per una configurazione desktop preferisco le partizioni non elaborate. Il vantaggio principale che posso vedere da LVM è la flessibilità di spostare e ridimensionare gli FS quando devi avere un tempo di attività elevato su un server - se non ne hai bisogno, gparted è più semplice e presenta meno rischi di perdita di dati.

LVM richiede molta attenzione nella configurazione della cache in scrittura a causa di hypervisor VM, cache in scrittura su disco rigido/SSD e così via, ma lo stesso vale per l'utilizzo di Linux come server DB. La mancanza di supporto dalla maggior parte degli strumenti (gparted compresi i calcoli delle dimensioni critiche e testdisk etc) lo rende più difficile da usare di quanto dovrebbe essere.

Se utilizzi LVM, fai molta attenzione con gli snapshot:usa gli snapshot VM/cloud se possibile, oppure esamina ZFS/btrfs per evitare completamente LVM:potresti scoprire che ZFS o btrfs è sufficientemente maturo rispetto a LVM con snapshot.

In conclusione:se non conosci i problemi sopra elencati e come risolverli, è meglio non utilizzare LVM.

Soluzione 2:

Io [+1] quel post, e almeno per me penso che la maggior parte dei problemi esista. Li ho visti mentre eseguivano alcuni 100 server e alcuni 100 TB di dati. Per me l'LVM2 in Linux sembra una "idea intelligente" che qualcuno ha avuto. Come alcuni di questi, a volte si rivelano "non intelligenti". non avere gli stati del kernel e dello spazio utente (lvmtab) rigorosamente separati potrebbe essere sembrato davvero intelligente da eliminare, perché possono esserci problemi di corruzione (se non si ottiene il codice giusto)

Beh, solo che questa separazione c'era per una ragione - le differenze mostrano con la gestione della perdita di PV e la riattivazione online di un VG con PV mancanti per riportarli in gioco - Ciò che è un gioco da ragazzi su "LVM originali" (AIX, HP-UX) si trasforma in merda su LVM2 da allora la gestione dello stato non è abbastanza buona. E non farmi nemmeno parlare del rilevamento della perdita del quorum (haha) o della gestione dello stato (se rimuovo un disco, non verrà contrassegnato come non disponibile. Non nemmeno avere la dannata colonna di stato)

Ri:stabilità pvmove ... perché è

pvmove perdita di dati

un articolo di così alto livello sul mio blog, hmmm? Proprio ora guardo un disco in cui i dati fisici di lvm sono ancora appesi allo stato da metà pvmove. Ci sono state alcune perdite di memoria, penso, e l'idea generale è una buona cosa copiare i dati del blocco live dallo spazio utente è semplicemente triste. Bella citazione dall'elenco lvm "sembra che vgreduce --missing non gestisca pvmove" Significa infatti che se un disco si stacca durante pvmove, lo strumento di gestione lvm cambia da lvm a vi. Oh, e c'è stato anche un bug in cui pvmove continua dopo un errore di lettura/scrittura del blocco e di fatto non scrive più dati sul dispositivo di destinazione. WTF?

Ri:istantanee Il CoW viene eseguito in modo non sicuro, aggiornando i NUOVI dati nell'area lv dello snapshot e quindi riunendoli una volta eliminato lo snap. Ciò significa che si verificano forti picchi di IO durante il merge-back finale di nuovi dati nel LV originale e, cosa molto più importante, si ha anche un rischio molto più elevato di danneggiamento dei dati, poiché l'istantanea non verrà interrotta una volta raggiunto il muro, ma l'originale.

Il vantaggio è nelle prestazioni, facendo 1 scrittura invece di 3. Scegliere l'algoritmo veloce ma non sicuro è qualcosa che ovviamente ci si aspetta da persone come VMware e MS, su "Unix" preferirei indovinare che le cose sarebbero "fatte bene". non ho riscontrato molti problemi di prestazioni fintanto che ho l'archivio di backup delle istantanee su un diverso unità disco rispetto ai dati primari (e il backup su un altro ancora, ovviamente)

Ri:Barriere Non sono sicuro che si possa dare la colpa a LVM. Era un problema di devmapper, per quanto ne so. Ma ci può essere qualche colpa per non essersi davvero preoccupati di questo problema almeno dal kernel 2.6 fino al 2.6.33 AFAIK Xen è l'unico hypervisor che utilizza O_DIRECT per le macchine virtuali, il problema utilizzato essere quando è stato usato "loop" perché il kernel avrebbe comunque memorizzato nella cache usando quello. Virtualbox ha almeno alcune impostazioni per disabilitare cose come questa e Qemu/KVM generalmente sembra consentire la memorizzazione nella cache. Anche tutti i FUSE FS hanno problemi lì (no O_DIRECT)

Ri:Taglie Penso che LVM faccia "arrotondamento" della dimensione visualizzata. Oppure utilizza GiB. Ad ogni modo, devi usare la dimensione VG Pe e moltiplicarla per il numero LE del LV. Ciò dovrebbe fornire la dimensione netta corretta e tale problema è sempre un problema di utilizzo. È aggravato dai filesystem che non notano una cosa del genere durante fsck/mount (ciao, ext3) o non hanno un "fsck" online funzionante -n" (ciao, ext3)

Ovviamente sta dicendo che non puoi trovare buone fonti per tali informazioni. "quanti LE per il VRA?" "qual è l'offset fisico per PVRA, VGDA, ... ecc."

Rispetto a quello originale LVM2 è il primo esempio di "Chi non capisce UNIX è condannato a reinventarlo, male".

Aggiornamento alcuni mesi dopo:ormai ho raggiunto lo scenario "istantanea completa" per un test. Se si riempiono, l'istantanea si blocca, non il LV originale. Mi sbagliavo lì quando l'avevo postato per la prima volta. Ho raccolto informazioni sbagliate da qualche documento, o forse l'avevo capito. Nei miei setup ero sempre stato molto paranoico a non farli riempire e quindi non ho mai finito per correggere. È anche possibile estendere/ridurre le istantanee, il che è un piacere.

Quello che non sono ancora riuscito a risolvere è come identificare l'età di uno snapshot. Per quanto riguarda le loro prestazioni, c'è una nota sulla pagina del progetto fedora "thinp" che dice che la tecnica dello snapshot è in fase di revisione in modo che non diventino più lenti con ogni istantanea. Non so come lo stiano implementando.

Soluzione 3:

Se prevedi di utilizzare le istantanee per i backup, preparati a un notevole calo delle prestazioni quando è presente l'istantanea. altrimenti va tutto bene. Utilizzo lvm in produzione da un paio d'anni su dozzine di server, anche se il motivo principale per cui lo utilizzo è l'istantanea atomica, non la capacità di espandere facilmente i volumi.

A proposito, se utilizzerai un'unità da 1 TB, ricorda l'allineamento delle partizioni:questa unità molto probabilmente ha settori fisici da 4kB.

Soluzione 4:

Pur fornendo un'interessante finestra sullo stato di LVM oltre 10 anni fa, la risposta accettata è ora totalmente obsoleta. Moderno (es. LVM post-2012):

• Rispetta le richieste di sincronizzazione/barriera
• ha capacità di snapshot veloci e affidabili sotto forma di lvmthin
• avere una cache SSD stabile tramite lvmcache e una policy di writeback veloce per NVMe/NVDIMM/Optane tramite dm-writecache
• ottimizzatore di dati virtuali (vdo ) supporto grazie a lvmvdo
• RAID integrato e per volume grazie a lvmraid
• allineamento automatico a 1 MB o 4 MB (a seconda della versione), evitando completamente qualsiasi problema di allineamento 4K (a meno che non si utilizzi LVM su una partizione non allineata)
• eccellente supporto per estendere un volume, soprattutto quando lo si fa aggiungendo altri dispositivi a blocchi (che semplicemente non è possibile quando si usa un filesystem classico come ext4/xfs sopra una semplice partizione)
• una mailing list eccellente, amichevole ed estremamente utile su [email protected]

Ovviamente, questo non significa che hai sempre utilizzare LVM:la regola d'oro per l'archiviazione è evitare livelli non necessari. Ad esempio, per macchine virtuali semplici si può sicuramente procedere solo con la partizione classica. Ma se apprezzi una qualsiasi delle funzionalità di cui sopra, LVM è uno strumento estremamente utile che dovrebbe essere nella cassetta degli attrezzi di qualsiasi serio amministratore di sistema Linux.

Soluzione 5:

Adamo,

Un altro vantaggio:puoi aggiungere un nuovo volume fisico (PV), spostare tutti i dati in quel PV e quindi rimuovere il vecchio PV senza alcuna interruzione del servizio. Ho usato questa capacità almeno quattro volte negli ultimi cinque anni.

Uno svantaggio che non ho ancora notato chiaramente:c'è una curva di apprendimento piuttosto ripida per LVM2. Principalmente nell'astrazione che crea tra i tuoi file e il supporto sottostante. Se lavori solo con poche persone che condividono le faccende su una serie di server, potresti trovare la complessità aggiuntiva opprimente per il tuo team nel suo insieme. I team più grandi dedicati al lavoro IT generalmente non avranno questo problema.

Ad esempio, lo usiamo ampiamente qui al lavoro e ci siamo presi del tempo per insegnare a tutto il team le basi, il linguaggio e gli elementi essenziali sul ripristino di sistemi che non si avviano correttamente.

Un'avvertenza specifica da sottolineare:se si esegue l'avvio da un volume logico LVM2, si rende difficile trovare le operazioni di ripristino quando il server si arresta in modo anomalo. Knoppix e i suoi amici non hanno sempre le cose giuste per questo. Quindi, abbiamo deciso che la nostra directory /boot sarebbe stata su una propria partizione e sarebbe stata sempre piccola e nativa.

Nel complesso, sono un fan di LVM2.