Limite prático do número de snapshots do btrfs?

Question

Estou pensando em usar o btrfs em minha unidade de dados para poder usar o snapper , ou algo parecido com o snapper, para tirar instantâneos com base no tempo. Acredito que isso permitirá que eu procure versões antigas dos meus dados. Isso seria um acréscimo ao meu backup atual fora do local, já que uma falha no drive eliminaria os dados e os instantâneos.

Do meu ponto de vista, os snapshots do btrfs não ocupam muito espaço (metadados e os blocos que foram alterados, além de alguma sobrecarga), então o espaço não parece ser uma restrição.

Se eu tiver um milhão de instantâneos (por exemplo, um instantâneo a cada minuto por dois anos) isso causaria estragos, supondo que eu tenha espaço em disco suficiente para os dados, os dados alterados e os metadados?

Se houver um limite prático no número de instantâneos, isso depende do número de arquivos e / ou do tamanho dos arquivos?

    

Answer 1

Embora tecnicamente não haja limite quanto ao número de instantâneos, perguntei no BTRFS lista de discussão :

The (practical) answer depends to some extent on how you use btrfs.

Btrfs does have scaling issues due to too many snapshots (or actually the reflinks snapshots use, dedup using reflinks can trigger the same scaling issues), and single to low double-digits of snapshots per snapshotted subvolume remains the strong recommendation for that reason.

But the scaling issues primarily affect btrfs maintenance commands themselves, balance, check, subvolume delete. While millions of snapshots will make balance for example effectively unworkable (it'll sort of work but could take months), normal filesystem operations like reading and saving files doesn't tend to be affected, except to the extent that fragmentation becomes an issue (tho cow filesystems such as btrfs are noted for fragmentation, unless steps like defrag are taken to reduce it).

Parece que o uso de snapshots como um backup de arquivamento similar ao time machine / snapper não é uma boa ideia.

    

Answer 2

Como alguém que está usando um sistema de arquivos btrfs com Arch Linux há quase 2 anos, posso afirmar com segurança que não parece haver um limite prático para o número de instantâneos que podem ser facilmente alcançados. Existem algumas ressalvas embora. O sistema de arquivos btrfs pode levar à fragmentação. Portanto, é aconselhável usar o recurso de desfragmentação online incorporado em btrfs . Além disso, é possível fazer bom uso do recurso de compactação de btrfs . Essas medidas devem atender a maioria dos problemas de desempenho que podem surgir de maneira sensata em um computador razoavelmente decente da criação de muitos instantâneos.

Como você deve saber, btrfs trata os subvolumes como sistemas de arquivos e, portanto, o número de instantâneos é de fato limitado: ou seja, pelo tamanho dos arquivos. De acordo com o btrfs wiki, o tamanho máximo de arquivo que pode ser alcançado é 2^64 byte == 16 EiB ^[1] .

Além dessas limitações, sempre pode haver problemas quando você fica sem espaço sem que você imediatamente o reconheça, pois a verificação de espaço livre em btrfs filesystems às vezes pode ser complicada, ou seja, sem diferenciar entre diferentes métodos de medição espaço em um sistema de arquivos btrfs pode-se facilmente usar a faixa de qual quantidade de espaço é realmente deixado. Uma maneira possível de evitar esse cenário é o uso de cota. Isso garante que os usuários (ou o usuário, se for apenas um) possam usar apenas uma certa quantidade de espaço. Este conceito é muito discutido aqui e também aqui .

Por último, mas não menos importante, um aviso: Não sou especialista em btrfs filesystems e li apenas sobre essas coisas quando tive a mesma pergunta há algum tempo. Além disso, há sempre o problema de que btrfs é um "alvo em movimento rápido" (palavras bonitas sendo roubadas de uma página wiki Arch Linux ), então as coisas podem mudar.

    

Answer 3

Você pode ter um total combinado de 2 ⁶⁴ instantâneos e subvolumes.

A página btrfs design wiki diz (minha opinião):

Subvolumes are basically a named btree that holds files and directories. They have inodes inside the tree of tree roots and can have non-root owners and groups. Subvolumes can be given a quota of blocks, and once this quota is reached no new writes are allowed. All of the blocks and file extents inside of subvolumes are reference counted to allow snapshotting. Up to 2⁶⁴ subvolumes may be created on the FS.

Snapshots are identical to subvolumes, but their root block is initially shared with another subvolume. When the snapshot is taken, the reference count on the root block is increased, and the copy on write transaction system ensures changes made in either the snapshot or the source subvolume are private to that root. Snapshots are writable, and they can be snapshotted again any number of times. If read only snapshots are desired, their block quota is set to one at creation time.