Perigos e advertências do LVM

Recentemente, comecei a usar o LVM em alguns servidores para discos rígidos maiores que 1 TB. Eles são úteis, expansíveis e fáceis de instalar. No entanto, não consegui encontrar nenhum dado sobre os perigos e advertências do LVM.

Quais são as desvantagens do uso do LVM?

Sumário

Riscos do uso de LVM:

• Vulnerável para gravar problemas de cache com o hypervisor SSD ou VM
• Mais difícil de recuperar dados devido a estruturas em disco mais complexas
• Mais difícil de redimensionar os sistemas de arquivos corretamente
• Instantâneos são difíceis de usar, lentos e com erros
• Requer alguma habilidade para configurar corretamente, considerando esses problemas

Os dois primeiros problemas de LVM se combinam: se o cache de gravação não estiver funcionando corretamente e você tiver uma perda de energia (por exemplo, falha no PSU ou no UPS), é possível que você tenha que se recuperar do backup, o que significa um tempo de inatividade significativo. Um dos principais motivos para usar o LVM é o tempo de atividade mais alto (ao adicionar discos, redimensionar sistemas de arquivos, etc.), mas é importante corrigir a configuração do cache de gravação para evitar que o LVM reduza o tempo de atividade.

- Atualizado em dezembro de 2018: material de snapshot atualizado, incluindo estabilidade do ZFS e btrfs como alternativas aos snapshots do LVM

Atenuando os riscos

O LVM ainda pode funcionar bem se você:

• Obtenha a configuração correta do cache de gravação em hypervisor, kernel e SSDs
• Evite instantâneos do LVM
• Use versões recentes do LVM para redimensionar sistemas de arquivos
• Tenha bons backups

Detalhes

Eu pesquisei isso bastante no passado, tendo experimentado alguma perda de dados associada ao LVM. Os principais riscos e problemas do LVM que eu conheço são:

Vulnerável ao cache de gravação no disco rígido devido a hipervisores de VM, cache de disco ou kernels antigos do Linux e dificulta a recuperação de dados devido a estruturas mais complexas no disco - veja abaixo para obter detalhes. Eu vi configurações completas do LVM em vários discos corrompidas sem chance de recuperação, e o LVM mais o cache de gravação no disco rígido são uma combinação perigosa.

• O cache de gravação e a reordenação de gravação pelo disco rígido são importantes para o bom desempenho, mas podem falhar ao liberar os blocos no disco corretamente devido a hipervisores de VM, cache de gravação do disco rígido, kernels antigos do Linux etc.
  • Barreiras de gravação significa que o kernel garante que ele concluirá determinadas gravações de disco antes da gravação de disco "barreira", para garantir que os sistemas de arquivos e o RAID possam se recuperar no caso de uma súbita perda de energia ou travamento. Essas barreiras podem usar uma operação FUA (Force Unit Access) para gravar imediatamente certos blocos no disco, o que é mais eficiente do que uma descarga de cache completa. As barreiras podem ser combinadas com o enfileiramento eficiente de comandos com tags / nativos (emitindo várias solicitações de E / S de disco de uma só vez) para permitir que o disco rígido execute um novo pedido inteligente de gravação sem aumentar o risco de perda de dados.
• Os hipervisores de VM podem ter problemas semelhantes: a execução do LVM em um convidado do Linux sobre um hipervisor de VM, como VMware, Xen , KVM, Hyper-V ou VirtualBox, pode criar problemas semelhantes a um kernel sem barreiras de gravação, devido ao cache de gravação e gravação. -encomenda. Verifique cuidadosamente a documentação do hypervisor para uma opção de "liberação para disco" ou cache de gravação (presente no KVM , VMware , Xen , VirtualBox e outros) - e teste-a com sua configuração. Alguns hipervisores, como o VirtualBox, têm uma configuração padrão que ignora qualquer liberação de disco do convidado.
• Os servidores corporativos com LVM sempre devem usar um controlador RAID com bateria e desativar o cache de gravação no disco rígido (o controlador possui um cache de gravação com bateria que é rápido e seguro) - consulte este comentário pelo autor desta entrada da XFS FAQ . Também pode ser seguro desativar as barreiras de gravação no kernel, mas o teste é recomendado.
• Se você não tiver um controlador RAID com bateria, a desativação do cache de gravação no disco rígido diminuirá significativamente as gravações, mas tornará o LVM seguro. Você também deve usar o equivalente à data=orderedopção do ext3 (ou data=journalpara segurança extra), além barrier=1de garantir que o cache do kernel não afete a integridade. (Ou use o ext4, que habilita barreiras por padrão .) Essa é a opção mais simples e fornece boa integridade de dados ao custo do desempenho. (O Linux mudou a opção ext3 padrão para a mais perigosa há data=writebackalgum tempo, portanto, não confie nas configurações padrão do FS.)
• Para desativar o cache de gravação do disco rígido : adicione hdparm -q -W0 /dev/sdXpara todas as unidades /etc/rc.local(para SATA) ou use sdparm para SCSI / SAS. No entanto, de acordo com esta entrada nas Perguntas frequentes do XFS (que é muito bom neste tópico), uma unidade SATA pode esquecer essa configuração após uma recuperação de erro da unidade - portanto, você deve usar SCSI / SAS ou, se você deve usar SATA, coloque o comando comando hdparm em um trabalho cron executando a cada minuto aproximadamente.
• Para manter o cache de gravação SSD / disco rígido habilitado para obter melhor desempenho: essa é uma área complexa - consulte a seção abaixo.
• Se você estiver usando unidades de formato avançado, ou seja, setores físicos de 4 KB, veja abaixo - desativar o cache de gravação pode ter outros problemas.
• O no-break é essencial tanto para a empresa quanto para o SOHO, mas não o suficiente para tornar o LVM seguro: qualquer coisa que cause uma falha grave ou perda de energia (por exemplo, falha no no-break, falha no PSU ou exaustão da bateria do laptop) pode perder dados nos caches do disco rígido.
• Kernels Linux muito antigos (2.6.x de 2009) : Há suporte incompleto à barreira de gravação em versões muito antigas do kernel, 2.6.32 e anteriores (o 2.6.31 tem algum suporte , enquanto o 2.6.33 funciona para todos os tipos de destino do dispositivo) - O RHEL 6 usa 2.6.32 com muitos patches. Se esses kernels 2.6 antigos não tiverem sido corrigidos para esses problemas, uma grande quantidade de metadados do FS (incluindo diários) poderá ser perdida por uma falha grave que deixa os dados nos buffers de gravação dos discos rígidos (por exemplo, 32 MB por unidade para unidades SATA comuns). Perder 32 MB dos metadados e dados de diário mais escritos do FS, que o kernel pensa que já está no disco, geralmente significa muita corrupção do FS e, portanto, perda de dados.
• Resumo: você deve cuidar do sistema de arquivos, RAID, hypervisor VM e configuração do disco rígido / SSD usado com o LVM. Você deve ter backups muito bons se estiver usando o LVM e não se esqueça de fazer backup específico dos setores de metadados, configuração da partição física, MBR e inicialização de volume do LVM. Também é aconselhável usar unidades SCSI / SAS, pois é menos provável que elas mentam sobre como eles fazem o cache de gravação - é necessário mais cuidado para usar unidades SATA.

Mantendo o cache de gravação ativado para desempenho (e lidando com as unidades em repouso)

Uma opção mais complexa mas de desempenho é manter o cache de gravação SSD / disco rígido ativado e confiar nas barreiras de gravação do kernel que trabalham com o LVM no kernel 2.6.33+ (verifique novamente procurando mensagens de "barreira" nos logs).

Você também deve garantir que a configuração do RAID, a configuração do hipervisor da VM e o sistema de arquivos usem barreiras de gravação (isto é, exige que a unidade libere gravações pendentes antes e depois dos principais metadados / gravações no diário). O XFS usa barreiras por padrão, mas o ext3 não , portanto, com o ext3, você deve usar barrier=1as opções de montagem e ainda usar data=orderedou data=journalcomo acima.

• Infelizmente, alguns discos rígidos e SSDs mentem sobre se eles realmente liberaram seu cache no disco (particularmente unidades mais antigas, mas incluindo algumas unidades SATA e alguns SSDs corporativos ) - mais detalhes aqui . Há um ótimo resumo de um desenvolvedor de XFS .
• Existe uma ferramenta de teste simples para unidades de mentir (script Perl), ou veja este plano de fundo com outra ferramenta de teste para reordenação de gravação como resultado do cache da unidade. Esta resposta abrangeu testes semelhantes de unidades SATA que descobriram um problema de barreira de gravação no RAID de software - esses testes realmente exercitam toda a pilha de armazenamento.
• As unidades SATA mais recentes que oferecem suporte ao Native Command Queuing (NCQ) podem ter menos chances de mentir - ou talvez tenham um bom desempenho sem o cache de gravação devido ao NCQ, e poucas unidades não podem desativar o cache de gravação.
• As unidades SCSI / SAS geralmente são boas, pois não precisam de cache de gravação para ter um bom desempenho (por meio do enfileiramento de comandos com tag SCSI , semelhante ao NCQ da SATA).
• Se seus discos rígidos ou SSDs mentirem sobre a liberação do cache para o disco, você realmente não pode confiar nas barreiras de gravação e deve desativar o cache de gravação. Esse é um problema para todos os sistemas de arquivos, bancos de dados, gerenciadores de volume e RAID de software , não apenas o LVM.

Os SSDs são problemáticos porque o uso do cache de gravação é crítico para a vida útil do SSD. É melhor usar um SSD que tenha um supercapacitor (para habilitar a liberação do cache em caso de falta de energia e, portanto, permitir que o cache seja gravado de volta, não gravado).

• A maioria dos SSDs corporativos deve estar bem no controle de cache de gravação, e alguns incluem supercapacitores.
• Alguns SSDs mais baratos têm problemas que não podem ser corrigidos com a configuração do cache de gravação - a lista de discussão do projeto PostgreSQL e a página wiki Reliable Writes são boas fontes de informação. Os SSDs dos consumidores podem ter grandes problemas de cache de gravação que causarão perda de dados e não incluem supercapacitores, por isso são vulneráveis ​​a falhas de energia que causam corrupção.

Configuração avançada da unidade de formato - cache de gravação, alinhamento, RAID, GPT

• Com as unidades Advanced Format mais recentes que usam 4 setores físicos de KiB, pode ser importante manter o cache de gravação de unidade ativado, uma vez que a maioria dessas unidades atualmente emula setores lógicos de 512 bytes ( "emulação de 512" ), e algumas até afirmam ter um físico de 512 bytes. setores enquanto realmente usa 4 KiB.
• Desativar o cache de gravação de uma unidade de Formato Avançado pode causar um impacto muito grande no desempenho se o aplicativo / kernel estiver executando gravações de 512 bytes, pois essas unidades dependem do cache para acumular gravações de 8 x 512 bytes antes de executar um único físico de 4 KiB Escreva. O teste é recomendado para confirmar qualquer impacto se você desativar o cache.
• O alinhamento dos LVs em um limite de 4 KiB é importante para o desempenho, mas deve ocorrer automaticamente desde que as partições subjacentes dos PVs estejam alinhadas, já que o LVM Physical Extents (PEs) tem 4 MiB por padrão. O RAID deve ser considerado aqui - esta página de configuração do LVM e do software RAID sugere colocar o superbloco RAID no final do volume e (se necessário) usar uma opção pvcreatepara alinhar os PVs. Esse encadeamento de lista de email do LVM aponta para o trabalho realizado nos kernels durante 2011 e a questão das gravações em bloco parciais ao misturar discos com setores de 512 bytes e 4 KiB em um único LV.
• O particionamento da GPT com o Advanced Format precisa de cuidados, especialmente para discos de inicialização + raiz, para garantir que a primeira partição LVM (PV) inicie em um limite de 4 KiB.

Mais difícil recuperar dados devido a estruturas em disco mais complexas :

• Qualquer recuperação de dados LVM necessária após uma falha grave ou perda de energia (devido ao cache de gravação incorreto) é um processo manual, na melhor das hipóteses, porque aparentemente não existem ferramentas adequadas. O LVM é bom em fazer backup de seus metadados /etc/lvm, o que pode ajudar a restaurar a estrutura básica de LVs, VGs e PVs, mas não ajuda com os metadados perdidos do sistema de arquivos.
• Portanto, é provável que seja necessária uma restauração completa do backup. Isso envolve muito mais tempo de inatividade do que um fsck rápido baseado em diário quando não estiver usando o LVM, e os dados gravados desde o último backup serão perdidos.
• TestDisk , ext3grep , ext3undel e outras ferramentas podem recuperar partições e arquivos de discos não-LVM, mas não suportam diretamente a recuperação de dados LVM. O TestDisk pode descobrir que uma partição física perdida contém um PV do LVM, mas nenhuma dessas ferramentas entende os volumes lógicos do LVM. Ferramentas de gravação de arquivos como o PhotoRec e muitos outros funcionariam à medida que ignoram o sistema de arquivos para montar novamente arquivos de blocos de dados, mas essa é uma abordagem de último nível e de baixo nível para dados valiosos e funciona menos bem com arquivos fragmentados.
• A recuperação manual do LVM é possível em alguns casos, mas é complexa e demorada - veja este exemplo e isto , isto e isto para saber como recuperar.

Difícil redimensionar os sistemas de arquivos corretamente - o redimensionamento fácil do sistema de arquivos geralmente é oferecido como um benefício do LVM, mas você precisa executar meia dúzia de comandos do shell para redimensionar um FS baseado em LVM - isso pode ser feito com todo o servidor ainda ativo e, em alguns casos com o FS montado, mas eu nunca arriscaria o último sem backups atualizados e usando comandos pré-testados em um servidor equivalente (por exemplo, clone de recuperação de desastre do servidor de produção).

• Atualização: Versões mais recentes do lvextendsuporte à opção -r( --resizefs) - se disponível, é uma maneira mais segura e rápida de redimensionar o LV e o sistema de arquivos, principalmente se você estiver diminuindo o FS, e você pode pular esta seção.
• A maioria dos guias para redimensionar FSs baseados em LVM não leva em consideração o fato de que o FS deve ser um pouco menor que o tamanho do LV: explicação detalhada aqui . Ao reduzir um sistema de arquivos, você precisará especificar o novo tamanho da ferramenta de redimensionamento do FS, por exemplo, resize2fspara ext3, e para lvextendou lvreduce. Sem muito cuidado, os tamanhos podem ser ligeiramente diferentes devido à diferença entre 1 GB (10 ^ 9) e 1 GiB (2 ^ 30) ou a maneira como as várias ferramentas arredondam os tamanhos para cima ou para baixo.
• Se você não fizer os cálculos exatamente da maneira correta (ou usar algumas etapas adicionais além das mais óbvias), poderá acabar com um FS muito grande para o LV. Tudo ficará bem por meses ou anos, até que você preencha completamente o FS, e nesse ponto você sofrerá uma grave corrupção - e, a menos que esteja ciente desse problema, é difícil descobrir o porquê, pois você também pode ter erros reais de disco até então. que obscurecem a situação. (É possível que esse problema afete apenas a redução do tamanho dos sistemas de arquivos - no entanto, é claro que o redimensionamento dos sistemas de arquivos em qualquer direção aumenta o risco de perda de dados, possivelmente devido a erro do usuário.)

• Parece que o tamanho do VE deve ser maior que o tamanho do FS em 2 vezes o tamanho da extensão física (PE) do LVM - mas verifique o link acima para obter detalhes, pois a fonte para isso não é autorizada. Geralmente, permitir 8 MiB é suficiente, mas pode ser melhor permitir mais, por exemplo, 100 MiB ou 1 GiB, apenas para garantir a segurança. Para verificar o tamanho do PE e o seu volume lógico + tamanhos de FS, usando blocos de 4 KiB = 4096 bytes:

  Mostra o tamanho do PE em KiB:
  vgdisplay --units k myVGname | grep "PE Size"
  
  tamanho de todos os LVs:
  lvs --units 4096b
  
  tamanho de (ext3) FS, assume o tamanho de bloco de 4 KiB FS:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• Por outro lado, uma configuração não-LVM faz redimensionar as FS muito confiável e fácil - executar Gparted e redimensionar O FSS necessário, então ele irá fazer tudo para você. Nos servidores, você pode usar a partedpartir do shell.

  • Geralmente é melhor usar o Live CD do Gparted ou o Parted Magic , pois eles têm um Kparted & kernel recente e muitas vezes mais livre de bugs do que a versão da distro - uma vez perdi um FS inteiro devido ao Gparted da distro não atualizar as partições corretamente durante a execução núcleo. Se estiver usando o Gparted da distribuição, certifique-se de reiniciar imediatamente após alterar as partições para que a visualização do kernel esteja correta.

Os instantâneos são difíceis de usar, lentos e com erros - se o instantâneo ficar sem espaço pré-alocado, ele será descartado automaticamente . Cada captura instantânea de um determinado LV é um delta contra esse LV (não contra as capturas instantâneas anteriores) que pode exigir muito espaço ao capturar sistemas de arquivos com atividade de gravação significativa (cada captura instantânea é maior que a anterior). É seguro criar um LV de instantâneo com o mesmo tamanho do LV original, pois o instantâneo nunca ficará sem espaço livre.

Os instantâneos também podem ser muito lentos (o que significa 3 a 6 vezes mais lento que sem o LVM para esses testes do MySQL ) - veja esta resposta abordando vários problemas de instantâneos . A lentidão ocorre em parte porque os instantâneos requerem muitas gravações síncronas .

Os snapshots tiveram alguns bugs significativos, por exemplo, em alguns casos , podem tornar a inicialização muito lenta ou causar uma falha na inicialização completamente (porque o kernel pode aguardar o tempo de espera pelo FS raiz quando é um snapshot do LVM [corrigido na initramfs-toolsatualização Debian , março de 2015] )

• No entanto, muitos erros de condição de corrida de instantâneo foram aparentemente corrigidos até 2015.
• O LVM sem snapshots geralmente parece muito bem depurado, talvez porque os snapshots não são usados ​​tanto quanto os recursos principais.

Alternativas de captura instantânea - sistemas de arquivos e hipervisores de VM

Instantâneos de VM / nuvem:

• Se você estiver usando um hipervisor de VM ou um provedor de nuvem IaaS (por exemplo, VMware, VirtualBox ou Amazon EC2 / EBS), seus instantâneos geralmente são uma alternativa muito melhor aos instantâneos de LVM. Você pode facilmente tirar um instantâneo para fins de backup (mas considere congelar o FS antes de fazê-lo).

Instantâneos do sistema de arquivos:

• Os snapshots no nível do sistema de arquivos com ZFS ou btrfs são fáceis de usar e geralmente melhores que o LVM, se você estiver usando bare metal (mas o ZFS parece muito mais maduro, apenas mais problemas para instalar):

  • ZFS: agora existe uma implementação do ZFS do kernel , que está em uso há alguns anos
  • btrfs : ainda não está pronto para uso em produção ( mesmo no openSUSE que o entrega por padrão e possui uma equipe dedicada ao btrfs), enquanto o RHEL parou de suportá-lo), e suas ferramentas fsck e de reparo ainda estão em desenvolvimento.

Instantâneos para backups online e fsck

As capturas instantâneas podem ser usadas para fornecer uma fonte consistente para backups, desde que você tenha cuidado com o espaço alocado (idealmente, a captura instantânea é do mesmo tamanho do backup do LV). O excelente rsnapshot (desde 1.3.1) até gerencia a criação / exclusão de instantâneos do LVM para você - veja este HOWTO no rsnapshot usando o LVM . No entanto, observe os problemas gerais dos instantâneos e que um instantâneo não deve ser considerado um backup por si só.

Você também pode usar os snapshots do LVM para fazer um fsck on-line: faça o snapshot do LV e do fsck o snapshot, enquanto ainda estiver usando o FS principal que não é do snapshot - descrito aqui - no entanto, não é totalmente simples, portanto, é melhor usar o e2croncheck conforme descrito por Ted Ts 'o , mantenedor do ext3.

Você deve "congelar" o sistema de arquivos temporariamente enquanto tira o instantâneo - alguns sistemas de arquivos como ext3 e XFS fazem isso automaticamente quando o LVM cria o instantâneo.

Conclusões

Apesar de tudo isso, ainda uso o LVM em alguns sistemas, mas para uma configuração de área de trabalho, prefiro partições brutas. O principal benefício que vejo do LVM é a flexibilidade de mover e redimensionar FSs quando você precisa ter um tempo de atividade alto em um servidor - se você não precisar disso, o gparted é mais fácil e tem menos risco de perda de dados.

O LVM requer muito cuidado na configuração do cache de gravação devido aos hipervisores da VM, cache de gravação do disco rígido / SSD e assim por diante - mas o mesmo se aplica ao uso do Linux como servidor de banco de dados. A falta de suporte da maioria das ferramentas ( gpartedincluindo cálculos críticos de tamanho testdisketc.) torna mais difícil o uso do que deveria.

Se estiver usando o LVM, tome muito cuidado com os instantâneos: use instantâneos de VM / nuvem, se possível, ou investigue o ZFS / btrfs para evitar o LVM completamente - você pode achar que o ZFS ou btrs é suficientemente maduro em comparação com o LVM com instantâneos.

Conclusão: se você não conhece os problemas listados acima e como resolvê-los, é melhor não usar o LVM.

Eu [+1] nessa postagem e, pelo menos para mim, acho que a maioria dos problemas existe. Você os viu executando alguns 100 servidores e alguns 100 TB de dados. Para mim, o LVM2 no Linux parece uma "idéia inteligente" que alguém teve. Como alguns desses, eles acabam sendo "pouco inteligentes" às vezes. Ou seja, não ter os estados estritamente separados do kernel e do espaço do usuário (lvmtab) pode ter sido realmente inteligente para acabar com isso, porque pode haver problemas de corrupção (se você não entender o código corretamente)

Bem, apenas que essa separação ocorreu por uma razão - as diferenças são mostradas com o tratamento de perdas de PV e a reativação on-line de um VG com PVs ausentes, ou seja, para trazê-los de volta ao jogo - O que é fácil nos "LVMs originais" (AIX , HP-UX) se transforma em lixo no LVM2, pois o tratamento de estado não é bom o suficiente. E nem me fale sobre detecção de perda de quorum (haha) ou manipulação de estado (se eu remover um disco, isso não será sinalizado como indisponível. Ele nem tem a coluna de status)

Re: estabilidade pvmove ... por que é

perda de dados pvmove

um artigo tão bem classificado no meu blog, hmmm? Agora, eu olho para um disco em que os dados phyiscal lvm ainda estão suspensos no estado no meio do pvmove. Acho que existem alguns erros de memória, e a ideia geral de que é bom copiar dados de blocos ao vivo do espaço do usuário é triste. Uma boa citação da lista do lvm "parece que o vgreduce --missing não lida com o pvmove" Significa que, se um disco for desconectado durante o pvmove, a ferramenta de gerenciamento do lvm mudará do lvm para o vi. Ah, e também houve um bug em que o pvmove continua após um erro de leitura / gravação em bloco e, de fato, não grava mais dados no dispositivo de destino. WTF?

Re: Snapshots O CoW é feito de maneira insegura, atualizando os NOVOS dados na área lv do snapshot e, em seguida, mesclando novamente quando você excluir o snap. Isso significa que você tem picos de IO pesados ​​durante a mesclagem final de novos dados no LV original e, muito mais importante, é claro que você também tem um risco muito maior de corrupção de dados, porque o snapshot não será quebrado assim que você atingir o parede, mas o original.

A vantagem está no desempenho, fazer 1 gravação em vez de 3. Escolher o algoritmo rápido, mas não seguro, é algo que obviamente se espera de pessoas como VMware e MS, no "Unix". Não vi muitos problemas de desempenho desde que eu tenha o armazenamento de backup de instantâneo em uma unidade de disco diferente dos dados primários (e backup para outro, é claro)

Re: Barreiras Não tenho certeza se alguém pode culpar o LVM. Era uma questão de devmapper, até onde eu sei. Mas pode haver alguma culpa por não se importar realmente com esse problema, pelo menos do kernel 2.6 até 2.6.33. O AFAIK Xen é o único hipervisor que usa O_DIRECT para as máquinas virtuais, o problema costumava ser quando "loop" era usado porque o kernel ainda armazenaria em cache usando isso. O Virtualbox tem pelo menos alguma configuração para desativar coisas como essa e o Qemu / KVM geralmente parece permitir o armazenamento em cache. Todos os FUSE FS também estão tendo problemas lá (sem O_DIRECT)

Re: Tamanhos Eu acho que LVM faz "arredondamento" do tamanho exibido. Ou ele usa GiB. De qualquer forma, você precisa usar o tamanho VG Pe e multiplicá-lo pelo número LE do LV. Isso deve fornecer o tamanho correto da rede e esse problema é sempre um problema de uso. É piorado por sistemas de arquivos que não percebem isso durante o fsck / mount (hello, ext3) ou não têm um "fsck -n" on-line (hello, ext3) em funcionamento

É claro que é revelador que você não consegue encontrar boas fontes para essas informações. "quantos LE para o VRA?" "qual é o deslocamento phyiscal para PVRA, VGDA, ... etc"

Comparado ao original, o LVM2 é o principal exemplo de "Quem não entende o UNIX está condenado a reinventá-lo mal".

Atualize alguns meses depois: já estou acessando o cenário "snapshot completo" para um teste. Se ficarem cheios, o instantâneo será bloqueado, não o LV original. Eu estava errado lá quando publiquei isso pela primeira vez. Peguei informações erradas de algum documento, ou talvez eu tivesse entendido. Nas minhas configurações, eu sempre fui muito paranóico em não deixá-los encher e, portanto, nunca acabei corrigido. Também é possível estender / reduzir snapshots, o que é um prazer.

O que ainda não consegui resolver é como identificar a idade de um instantâneo. Quanto ao seu desempenho, há uma nota na página do projeto "thinp" do fedora que diz que a técnica de snapshot está sendo revisada para que eles não fiquem mais lentos a cada snapshot. Não sei como eles estão implementando.

se você planeja usar snapshots para backups - esteja preparado para grandes ocorrências de desempenho quando o snapshot estiver presente. leia mais aqui . caso contrário, está tudo bem. uso o lvm em produção há alguns anos em dezenas de servidores, embora meu principal motivo para usá-lo seja a capacidade de snapshot atômico não expandir volumes facilmente.

Aliás, se você usar uma unidade de 1 TB, lembre-se do alinhamento de partições - essa unidade provavelmente possui setores físicos de 4kB.

Adão,

Outra vantagem: você pode adicionar um novo volume físico (PV), mover todos os dados para esse PV e remover o PV antigo sem interrupções de serviço. Eu usei essa capacidade pelo menos quatro vezes nos últimos cinco anos.

Uma desvantagem que ainda não vi apontada claramente: há uma curva de aprendizado um tanto íngreme para o LVM2. Principalmente na abstração criada entre seus arquivos e a mídia subjacente. Se você trabalha com apenas algumas pessoas que compartilham tarefas em um conjunto de servidores, poderá encontrar uma complexidade extra esmagadora para sua equipe como um todo. Equipes maiores dedicadas ao trabalho de TI geralmente não terão esse problema.

Por exemplo, usamos amplamente aqui no meu trabalho e levamos tempo para ensinar a toda a equipe o básico, o idioma e o essencial sobre a recuperação de sistemas que não inicializam corretamente.

Um aviso específico a ser destacado: se você inicializar a partir de um volume lógico LVM2, você encontrará dificuldades nas operações de recuperação quando o servidor travar. Knoppix e amigos nem sempre têm o material certo para isso. Então, decidimos que nosso diretório / boot estaria em sua própria partição e sempre seria pequeno e nativo.

No geral, sou fã de LVM2.