Pericoli e avvertenze su LVM

Di recente ho iniziato a utilizzare LVM su alcuni server per dischi rigidi di dimensioni superiori a 1 TB. Sono utili, espandibili e abbastanza facili da installare. Tuttavia, non sono riuscito a trovare dati sui pericoli e le avvertenze di LVM.

Quali sono gli svantaggi dell'utilizzo di LVM?

Sommario

Rischi derivanti dall'uso di LVM:

• Vulnerabile a scrivere problemi di cache con SSD o hypervisor VM
• Difficile recuperare i dati a causa di strutture su disco più complesse
• Difficile ridimensionare correttamente i filesystem
• Le istantanee sono difficili da usare, lente e buggy
• Richiede alcune abilità per configurare correttamente dati questi problemi

I primi due problemi di LVM si combinano: se la memorizzazione nella cache della scrittura non funziona correttamente e si verifica una perdita di energia (ad es. PSU o UPS), potrebbe essere necessario ripristinare il backup, il che significa tempi di inattività significativi. Un motivo chiave per l'utilizzo di LVM è il tempo di attività più elevato (quando si aggiungono dischi, ridimensionano i filesystem, ecc.), Ma è importante ottenere la corretta configurazione della cache di scrittura per evitare che LVM riduca effettivamente i tempi di attività.

- Aggiornato dicembre 2018: materiale istantaneo aggiornato, inclusa la stabilità di ZFS e btrfs come alternative alle istantanee LVM

Mitigare i rischi

LVM può ancora funzionare bene se:

• Configura la tua cache di scrittura direttamente in hypervisor, kernel e SSD
• Evita le istantanee LVM
• Usa le versioni LVM recenti per ridimensionare i filesystem
• Avere buoni backup

Dettagli

L'ho studiato un po 'in passato dopo aver sperimentato una perdita di dati associata a LVM. I principali rischi e problemi di LVM di cui sono a conoscenza sono:

Vulnerabile alla memorizzazione nella cache 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 configurazioni complete di LVM su diversi dischi corrotte senza alcuna possibilità di recupero e LVM più la memorizzazione nella cache del disco fisso sono una combinazione pericolosa.

• Scrivere la cache e scrivere il riordino dal disco rigido è importante per buone prestazioni, ma può non riuscire a svuotare correttamente i blocchi su disco a causa di hypervisor VM, cache di scrittura del disco rigido, vecchi kernel Linux, ecc.
  • Le barriere di scrittura indicano che il kernel garantisce che completerà determinate scritture del disco prima della scrittura del disco "barriera", per garantire che filesystem e RAID possano recuperare in caso di improvvisa perdita di potenza o crash. Tali barriere possono utilizzare un'operazione FUA (Force Unit Access) per scrivere immediatamente determinati blocchi sul disco, che è più efficiente di un flush completo della cache. Le barriere possono essere combinate con un efficiente accodamento dei comandi con tag / nativo (invio di più richieste di I / O su disco contemporaneamente) per consentire al disco rigido di eseguire un riordino in scrittura intelligente senza aumentare il rischio di perdita di dati.
• Gli hypervisor VM possono 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 scrittura nella cache e della scrittura -ordering. Controlla attentamente la documentazione del tuo hypervisor per l'opzione "flush to disk" o cache di scrittura (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 svuotamento del disco dal guest.
• I server aziendali con LVM devono sempre utilizzare un controller RAID con batteria e disabilitare la memorizzazione nella cache di scrittura sul disco rigido (il controller ha una cache di scrittura con batteria supportata che è veloce e sicura). Vedere questo commento dell'autore di questa voce FAQ 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 alimentato a batteria, la disabilitazione della memorizzazione nella cache di scrittura sul disco rigido rallenterà significativamente le scritture ma renderà LVM sicuro. Dovresti anche usare l'equivalente data=ordereddell'opzione ext3 (o data=journalper maggiore sicurezza), in più barrier=1per assicurarti che la cache del kernel non influisca sull'integrità. (Oppure usa ext4 che abilita le barriere di default .) Questa è l'opzione più semplice e fornisce una buona integrità dei dati a costo delle prestazioni. (Linux ha cambiato l'opzione ext3 predefinita in quella più pericolosa data=writebackqualche tempo fa, quindi non fare affidamento sulle impostazioni predefinite per FS.)
• Per disabilitare la memorizzazione nella cache del disco rigido : aggiungi hdparm -q -W0 /dev/sdXper tutte le unità in /etc/rc.local(per SATA) o usa 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 un ripristino dell'errore dell'unità, quindi è necessario utilizzare SCSI / SAS o, se è necessario utilizzare SATA, inserire il comando hdparm in un processo cron in esecuzione ogni minuto circa.
• Per mantenere abilitata la cache di scrittura SSD / disco rigido per prestazioni migliori: si tratta di un'area complessa - vedere la sezione seguente.
• Se si utilizzano unità di formattazione avanzata, ovvero settori fisici da 4 KB, vedere di seguito: la disabilitazione della memorizzazione nella cache di scrittura potrebbe avere altri problemi.
• L'UPS è fondamentale sia per le aziende che per i SOHO, ma non abbastanza per rendere LVM sicuro: qualsiasi cosa che causi un incidente o una perdita di corrente (ad es. Guasti dell'UPS, guasti dell'alimentatore o esaurimento della batteria del laptop) potrebbe perdere i dati nelle cache del disco rigido.
• Kernel Linux molto vecchi (2.6.x del 2009) : esiste un supporto incompleto alla barriera di scrittura nelle versioni del kernel molto vecchie, 2.6.32 e precedenti ( 2.6.31 ha un po 'di supporto , mentre 2.6.33 funziona per tutti i tipi di target 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). Perdere 32 MB dei metadati e dei dati del journal FS scritti più di recente, che il kernel ritiene sia già su disco, di solito significa molta corruzione di FS e quindi perdita di dati.
• Riepilogo: è necessario prestare attenzione al filesystem, al RAID, all'hypervisor VM e all'installazione del disco rigido / SSD utilizzati con LVM. È necessario disporre di backup molto validi se si utilizza LVM e assicurarsi di eseguire il backup specifico dei metadati LVM, dell'installazione della partizione fisica, dell'MBR e dei settori di avvio del volume. È anche consigliabile utilizzare le unità SCSI / SAS in quanto è meno probabile che mentano sul modo in cui scrivono la cache: è necessaria maggiore attenzione per utilizzare le unità SATA.

Mantenere la cache in scrittura abilitata per le prestazioni (e far fronte alle unità mentite)

Un'opzione più complessa ma performante è 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+ (ricontrollare cercando i messaggi "barriera" nei log).

Dovresti anche assicurarti che la configurazione RAID, la configurazione dell'hypervisor VM e il filesystem utilizzino le barriere di scrittura (cioè che l'unità debba svuotare le scritture in sospeso prima e dopo le scritture di metadati / journal chiave). XFS usa le barriere di default, ma ext3 no , quindi con ext3 dovresti usare barrier=1le opzioni di mount, e comunque usare data=orderedo data=journalcome sopra.

• Sfortunatamente, alcuni dischi rigidi e SSD mentono sul fatto che abbiano effettivamente scaricato la loro cache sul disco (in particolare le unità più vecchie, ma includendo alcune unità SATA e alcuni SSD aziendali ) - maggiori dettagli qui . C'è un ottimo riassunto di uno sviluppatore XFS .
• Esiste un semplice strumento di test per mentire unità (script Perl) o vedere questo sfondo con un altro strumento di test per riordinare la scrittura come risultato della cache dell'unità. Questa risposta ha riguardato test simili su unità SATA che hanno scoperto un problema di barriera di scrittura nel software RAID: questi test esercitano effettivamente l'intero stack di archiviazione.
• Le unità SATA più recenti che supportano Native Command Queuing (NCQ) potrebbero essere meno propense a mentire , o forse funzionano bene senza cache di scrittura a causa di NCQ e pochissime unità non possono disabilitare la cache di scrittura.
• Le unità SCSI / SAS sono generalmente OK in quanto non necessitano di memorizzazione nella cache di scrittura per funzionare bene (tramite SCSI Tagged Command Queuing , simile all'NCQ di SATA).
• Se i tuoi dischi rigidi o SSD mentono sul 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 filesystem, i database, i gestori di volumi e il software RAID , non solo per LVM.

Gli SSD sono problematici perché l'uso della cache di scrittura è fondamentale per la durata dell'SSD. È meglio usare un SSD che ha un supercondensatore (per abilitare lo svuotamento della cache in caso di interruzione dell'alimentazione e quindi abilitare la cache per essere riscrivibile e non riscrivibile).

• 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 di Reliable Writes sono buone fonti di informazioni. Gli SSD consumer possono avere gravi problemi di memorizzazione nella cache che causeranno la perdita di dati e non includono supercondensatori, quindi sono vulnerabili a interruzioni di corrente che causano corruzione.

Configurazione dell'unità di formattazione avanzata : scrittura nella cache, allineamento, RAID, GPT

• Con le unità di formato avanzato più recenti che utilizzano 4 settori fisici KiB, potrebbe essere importante mantenere abilitata la memorizzazione nella cache di scrittura delle unità, poiché la maggior parte di tali unità attualmente emula settori logici a 512 byte ( "512 emulazione" ) e alcuni addirittura affermano di avere un fisico a 512 byte settori mentre in realtà utilizza 4 KiB.
• La disattivazione della cache di scrittura di un'unità Advanced Format può causare un impatto molto elevato sulle prestazioni se l'applicazione / kernel esegue scritture a 512 byte, poiché tali unità si basano sulla cache per accumulare scritture da 8 x 512 byte prima di eseguire un singolo 4 KiB fisico Scrivi. Si consiglia di testare 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 RAID LVM e software suggerisce di posizionare il superblocco RAID alla fine del volume e (se necessario) di utilizzare un'opzione pvcreateper allineare i PV. Questo thread dell'elenco e-mail LVM indica il lavoro svolto nei kernel durante il 2011 e il problema delle scritture di blocchi parziali quando si mescolano dischi con settori a 512 byte e 4 KiB in un singolo LV.
• Il partizionamento GPT con Advanced Format richiede attenzione, specialmente per i dischi boot + root, per garantire che la prima partizione LVM (PV) inizi su un limite di 4 KiB.

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

• Qualsiasi ripristino dei dati LVM richiesto dopo un arresto anomalo o una perdita di corrente (a causa di una cache di scrittura errata) è nella migliore delle ipotesi un processo manuale, perché apparentemente non esistono strumenti adeguati. LVM è bravo a fare il backup dei suoi metadati /etc/lvm, il che può aiutare a ripristinare la struttura di base di LV, VG e PV, ma non aiuterà a perdere i metadati del filesystem.
• Pertanto è probabile che sia richiesto un ripristino completo dal backup. Ciò comporta tempi di inattività molto più lunghi di un veloce 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 recuperare partizioni e file da dischi non LVM ma non supportano direttamente il recupero 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 di file come PhotoRec e molti altri funzionerebbero mentre aggirano il filesystem per riassemblare i file dai blocchi di dati, ma questo è un approccio di ultima generazione a basso livello per dati preziosi e funziona meno bene con i file frammentati.
• Il recupero manuale LVM è possibile in alcuni casi, ma è complesso e richiede tempo: vedere questo esempio e questo , questo e questo per come recuperare.

Difficile ridimensionare correttamente i filesystem - il ridimensionamento semplice dei filesystem è spesso un 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 FS montato, ma non rischierei mai quest'ultimo senza backup aggiornati e utilizzando comandi pre-testati su un server equivalente (ad esempio clone di disaster recovery del server di produzione).

• Aggiornamento: versioni più recenti di lvextendsupportano l' opzione -r( --resizefs) - se disponibile, è un modo più sicuro e veloce per ridimensionare il LV e il filesystem, in particolare se stai riducendo l'FS e puoi saltare questa sezione.
• La maggior parte delle guide al ridimensionamento degli FS basati su LVM non tengono conto del fatto che l'FS deve essere leggermente più piccolo della dimensione dell'LV: spiegazione dettagliata qui . Quando si restringe un filesystem, sarà necessario specificare la nuova dimensione nello strumento di ridimensionamento di FS, ad es. resize2fsPer ext3, e su lvextendo lvreduce. Senza grande cura, le dimensioni possono essere leggermente diverse a causa della differenza tra 1 GB (10 ^ 9) e 1 GiB (2 ^ 30) o il modo in cui i vari strumenti arrotondano le dimensioni verso l'alto o verso il basso.
• Se non esegui i calcoli esattamente nel modo giusto (o usi alcuni passaggi extra oltre a quelli più ovvi), potresti finire con un FS troppo grande per il LV. Tutto sembrerà perfetto per mesi o anni, fino a quando non riempirai completamente il FS, a quel punto otterrai una grave corruzione - e se non sei a conoscenza di questo problema, è difficile scoprire perché, dato che potresti avere anche errori del disco reali da allora che offusca 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 LVM (PE) - 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 esempio 100 MiB o 1 GiB, solo per essere sicuri. Per verificare la dimensione PE e il volume logico + dimensioni FS, utilizzando 4 blocchi KiB = 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 4 blocchi 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 da eseguire Gparted e ridimensiona gli FS richiesti, quindi farà tutto per te. Sui server, è possibile utilizzare parteddalla shell.

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

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

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

Le istantanee hanno avuto alcuni bug significativi, ad esempio in alcuni casi possono rallentare l'avvio o causare il fallimento completo dell'avvio (perché il kernel può scadere in attesa del root FS quando si tratta di un'istantanea LVM [risolto initramfs-toolsnell'aggiornamento Debian , marzo 2015] ).

• Tuttavia, molti di condizione bug razziali snapshot erano apparentemente fissati entro il 2015.
• LVM senza snapshot in genere sembra abbastanza ben eseguito il debug, forse perché le snapshot non vengono utilizzate tanto quanto le funzionalità principali.

Alternative agli snapshot : filesystem e hypervisor VM

Snapshot VM / cloud:

• Se si utilizza un hypervisor VM o un provider cloud IaaS (ad esempio VMware, VirtualBox o Amazon EC2 / EBS), le loro istantanee sono spesso un'alternativa molto migliore alle istantanee LVM. Puoi facilmente scattare un'istantanea per scopi di backup (ma considera di congelare FS prima di farlo).

Istantanee del filesystem:

• Gli snapshot 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ù seccature da installare):

  • ZFS: ora esiste un'implementazione ZFS del kernel , che è in uso da alcuni anni
  • btrfs : non è ancora pronto per l'uso in produzione ( anche su openSUSE che lo spedisce di default e ha un team dedicato a btrfs), mentre RHEL ha smesso di supportarlo), e i suoi strumenti fsck e di riparazione sono ancora in fase di sviluppo.

Istantanee per backup online e fsck

Gli snapshot possono essere utilizzati per fornire una costante fonte per i backup, fino a quando si sta attenti con spazio assegnato (idealmente l'istantanea è la stessa dimensione del LV viene eseguito il backup). L'eccellente rsnapshot (dall'1.3.1) gestisce anche la creazione / eliminazione dell'istantanea LVM per te - vedi questo HOWTO su rsnapshot usando LVM . Tuttavia, notare i problemi generali con le istantanee e che un'istantanea non deve essere considerata un backup in sé.

Puoi anche usare le istantanee LVM per fare un fsck online: istantanea LV e fsck istantanea, mentre usi ancora il principale FS non-istantanea - descritto qui - tuttavia, non è del tutto semplice, quindi è meglio usare e2croncheck come descritto da Ted Ts 'o , manutentore di ext3.

Dovresti "bloccare" temporaneamente il filesystem mentre esegui l'istantanea: alcuni filesystem come ext3 e XFS lo faranno automaticamente quando LVM crea l'istantanea.

conclusioni

Nonostante tutto, 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 è necessario avere un elevato tempo di attività su un server - se non ne hai bisogno, gparted è più facile e ha meno rischi di perdita di dati.

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

Se si utilizza LVM, prestare molta attenzione agli snapshot: utilizzare gli snapshot VM / cloud, se possibile, o indagare su ZFS / btrfs per evitare completamente LVM - è possibile che ZFS o btrs siano sufficientemente maturi rispetto a LVM con snapshot.

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

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

Bene, solo che questa separazione esisteva per una ragione : le differenze si manifestano con la gestione delle perdite FV e la riattivazione online di un VG con PV mancanti, per farli rientrare in gioco - Qual è un gioco da ragazzi su "LVM originali" (AIX , HP-UX) si trasforma in merda su LVM2 poiché la gestione dello stato non è abbastanza buona. E non hanno nemmeno farmi parlare di rilevamento della perdita di quorum (haha) o lo stato di movimentazione (se rimuovere un disco, che non sarà contrassegnato come non disponibile. Non ha nemmeno avere la colonna dello stato maledetto)

Ri: stabilità pvmove ... perché lo è

perdita di dati pvmove

un articolo così importante sul mio blog, hmmm? Proprio ora guardo un disco in cui i dati lvm phyiscal sono ancora appesi allo stato da metà pvmove. Penso che ci siano stati alcuni memleak, e l'idea generale è una buona cosa copiare i dati dei blocchi live dallo spazio utente è solo triste. Bella citazione dall'elenco lvm "sembra vgreduce --missing non gestisce pvmove" Significa in effetti 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 in effetti non scrive più i 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 unendo nuovamente una volta eliminato lo snap. Ciò significa che hai forti picchi di I / O durante la fusione finale di nuovi dati nel LV originale e, cosa molto più importante, ovviamente hai anche un rischio molto più elevato di corruzione dei dati, perché non lo snapshot verrà interrotto una volta premuto il muro, ma l'originale.

Il vantaggio è nelle prestazioni, fare 1 scrive invece di 3. Scegliere l'algoritmo veloce ma non sicuro è qualcosa che ci si aspetta ovviamente 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'unità disco diversa rispetto ai dati primari (e ovviamente il backup su un altro ancora)

Ri: Barriere Non sono sicuro che si possa dare la colpa a LVM. È stato un problema devmapper, per quanto ne so. Ma ci può essere qualche colpa per non preoccuparsi davvero 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 era quando si utilizzava "loop" perché il kernel sarebbe ancora cache usando quello. Virtualbox ha almeno alcune impostazioni per disabilitare cose come questa e Qemu / KVM sembra generalmente consentire la memorizzazione nella cache. Anche tutti i FUSE FS hanno problemi lì (no O_DIRECT)

Ri: Dimensioni Penso che LVM faccia "l'arrotondamento" delle dimensioni visualizzate. Oppure usa GiB. Ad ogni modo, è necessario utilizzare la dimensione VG Pe e moltiplicarla per il numero LE della LV. Ciò dovrebbe fornire la dimensione netta corretta e tale problema è sempre un problema di utilizzo. È peggiorato dai filesystem che non notano una cosa del genere durante fsck / mount (ciao, ext3) o non hanno un "fsck -n" funzionante online (ciao, ext3)

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

Rispetto a quello originale LVM2 è il primo esempio di "Coloro che non comprendono UNIX sono condannati a reinventarlo, male".

Aggiornamento qualche mese dopo: ormai ho provato lo scenario "full snapshot" per un test. Se si riempiono, l'istantanea si blocca, non il LV originale. Ho sbagliato lì quando l'ho pubblicato per la prima volta. Ho raccolto informazioni errate da alcuni documenti o forse l'avevo capito. Nelle mie configurazioni ero sempre stato molto paranoico per non lasciarli riempire e quindi non sono mai stato corretto. È anche possibile estendere / ridurre le istantanee, il che è un piacere.

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

se si prevede di utilizzare le snapshot per i backup, prepararsi per le prestazioni più importanti quando è presente l'istantanea. leggi di più qui . altrimenti va tutto bene. sto usando lvm in produzione da un paio d'anni su dozzine di server, anche se il mio motivo principale per usarlo è l'istantanea atomica, non la capacità di espandere facilmente i volumi.

a proposito, se hai intenzione di utilizzare un'unità da 1 TB, ricorda l'allineamento delle partizioni: questa unità ha molto probabilmente settori fisici da 4kB.

Adamo,

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

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

Ad esempio, lo utilizziamo ampiamente qui nel mio lavoro e abbiamo impiegato del tempo per insegnare a tutto il team le basi, la lingua e gli elementi essenziali essenziali sul ripristino di sistemi che non si avviano correttamente.

Una avvertenza specifica da sottolineare: se si avvia da un volume logico LVM2, è difficile trovare le operazioni di ripristino in caso di arresto anomalo del server. Knoppix e gli amici non hanno sempre le cose giuste per quello. Quindi, abbiamo deciso che la nostra directory / boot sarebbe sulla sua stessa partizione e sarebbe sempre piccola e nativa.

Nel complesso, sono un fan di LVM2.