Instantâneo LVM sem copy-on-write

Question

Eu tenho experimentado com o LVM e como posso usá-lo para gerenciar dados no meu servidor NFS. Com tudo o que li sobre os instantâneos, ainda não sei como eles se comportam na vida real. Por que alguém precisa alocar espaço no instantâneo se eles são apenas um monte de ponteiros para os dados originais? Qual é o ponto do instantâneo se a modificação de arquivos na origem também acionar a modificação no instantâneo via copy-on-write? Eu pensei que o instantâneo deveria ser um ponto "estático" no tempo do original.

Minha expectativa é essa:

$ ls origin-data
> file1 file2
$ snapshot origin-data to origin-data-snapshot
$ modify origin-data and add new stuff
$ ls origin-data
> file1-modified file2 file3 file4
$ ls origin-data-snapshot
> file1 file2
$ sizeof origin-data-snapshot
> 0 bytes because they're all just pointers to blocks in origin-data!

Se eu for mal-entendido, explique e explique como os snapshots podem ser usados da maneira que estou esperando (como git commits, estáticos, sem alteração, ponteiros para dados em um ponto no tempo que não se importam sobre mudanças feitas na origem). Envolve instantâneos RO ou RW?

ATUALIZAÇÃO: Eu tenho experimentado com algumas partições de teste e tenho um pouco mais de compreensão. Ao montar a origem e o instantâneo, os novos arquivos na origem obviamente aparecem em algo como df -h , mas não no instantâneo. Enquanto isso, lvdisplay mostra essa porcentagem para "Alocado para instantâneo" aumentando. Usando arquivos de teste de 10mb e partições de teste de 1GB, vejo exatamente como essa porcentagem se comporta em relação aos meus dados, mas por que isso deve ser assim? Por que os novos dados aparecem no instantâneo e não na origem? Eu acho que os blocos se comportam como hard-links, pois os dados antigos ficam lá porque o snapshot aponta para ele enquanto novos blocos são criados próximos a eles, porque a origem aponta para o bloco novo e modificado. Não?

    

Answer 1

O custo de um instantâneo não pode ser zero bytes. Quando um bloco é alterado no volume de origem e você tem um instantâneo, uma cópia do bloco original antes da modificação deve ser feita - os dados originais devem estar disponíveis algunsh para que fiquem acessíveis a partir do instantâneo .

Isso é o tamanho do instantâneo (mais alguns metadados): cópias originais dos blocos que foram alterados na origem.

Observe que pode ser um "truque de contabilidade": uma implementação pode optar por não substituir o bloco original no disco, mas armazenar os novos dados em outro local e atualizar a lista de bloqueios de origem (ou o que for usado para rastrear ). Nesse caso, o instantâneo é "estático" de acordo com sua definição. Mas ainda faz com que o número total de blocos alocados cresça sempre que um bloco de origem é modificado. Este uso de espaço deve ser (an) contra o instantâneo.

Isso é verdadeiro para os snapshots RO e RW, exceto que é um pouco mais complexo no caso RW (você não quer sobrescrever um bloco que foi modificado no snapshot por um bloco original da fonte, se for esse o caso. modificado também, por exemplo).

    

Answer 2

Eu apenas olhei para este tópico, como o OP, o ponto central da confusão decorrente de "pensar em arquivos" enquanto o LVM trabalha com extensões físicas .

Normalmente, o LVM está localizado entre o HDD e um sistema de arquivos, cada uma dessas três camadas tem seu próprio termo para o conceito de "pedaços de bytes com o mesmo tamanho":

hdd: sectors (512 bytes) -> LVM: physical extents (4MB) -> file system: blocks (e.g. 4K)

Eu criei um dispositivo de loop grande de 200MB, 100MB para um volume lógico (testlv) e 60MB para um snapshot LV (snaplv).

O 100MB LV pode ser considerado como composto por 25 extensões físicas, cada uma representando 4 MB de blocos de sistemas de arquivos. O instantâneo LV inicialmente também faz referência a esses PEs, ele não usa seus próprios 15 PEs neste momento. Sempre que o usuário gravar no sistema de arquivos do volume lógico, o sistema de arquivos alterará o conteúdo de um ou mais blocos , que obviamente são armazenados em extensões físicas de LVM.

Modificar um PE de testlv significa, portanto:

1. copie o conteúdo do PE para um dos sobressalentes PEs ( copy-on-write )
2. altere a referência do snaplv para este "novo" PE
3. atualiza o conteúdo do testlv PE "original"

Obviamente, alterar um PE de snaplv é quase o mesmo, apenas a etapa final difere na medida em que é a cópia do PE do snaplv que será atualizada.