btrfs.readthedocs.io descreve o perfil "dup" como duplicação de dados em um único "dispositivo". A descrição, em vários locais naquele site, não esclarece se eles querem dizer uma unidade física com duas partições espelhadas ou uma partição com a duplicação oculta dentro.
Algumas descrições de "dup" sugerem que se trata de um raid1 especial ajustado para funcionar em um único dispositivo com duas partições, mas outras fontes parecem pensar que ele adiciona duplicação dentro de uma única partição. (É claro que o uso real do disco será o mesmo de qualquer maneira.) Parece-me que "dup" pode ser compatível com uma única partição, mas sem duplicação real, ou duas partições podem forçar um desempenho não ideal.
Isto é para HDD giratório usado para backup, não para acesso primário ("dup", protegendo contra bitrot. Outras cópias fora do local com hashes e somas de verificação). Estou ciente de que muitos SDD podem desduplicar internamente.
Alguém sabe o comportamento do perfil "dup" com certeza? Não sou habilidoso o suficiente em ler C para vasculhar os arquivos de origem do kernel.
Resumo
O uso pretendido do DUP é uma partição com a duplicação oculta dentro dela.
Resposta completa
O Btrfs não se importa se você fornece partição(ões) ou disco(s) inteiro(s), cada um deles é um dispositivo.
O perfil DUP foi projetado para ser usado em um único dispositivo. Você pode adicionar outro dispositivo e manter o perfil como DUP (e já que o 4.5.1
mkfs.btrfs
permitirá que você crie DUP em vários dispositivos desde o início), mas esse uso é subótimo: se você quiser redundância em vários dispositivos, prefira RAID1 ou superior; então o btrfs alocará cópias redundantes para dispositivos diferentes. Com o DUP não há tal requisito, cópias redundantes podem ser alocadas para um dispositivo. Observe que esse comportamento torna o DUP utilizável em um único dispositivo em primeiro lugar.O DUP em um único dispositivo tentará armazenar cada pedaço de dados (e/ou metadados) em dois locais físicos do dispositivo, esse é seu principal propósito. No caso de vários dispositivos, as duas cópias podem acabar em dispositivos diferentes ou podem acabar em um dispositivo. Independentemente disso, haverá "duplicação real", a menos que o dispositivo que recebeu as duas cópias decida desduplicá-las internamente (você parece estar ciente desse problema).
Usar DUP em dois dispositivos faz sentido quando os dispositivos são de tamanhos diferentes e, portanto, o RAID1 neles faria com que uma parte significativa do dispositivo maior não estivesse disponível para você.
Em qualquer caso, todo o gerenciamento realizado pelo btrfs será interno ao btrfs. O btrfs por si só não criará nenhuma nova partição(ões) que você possa ver
fdisk -l
ou algo assim.Em geral, há pouco sentido em usar duas ou mais partições do mesmo disco como dispositivos usados por um único btrfs (single filesystem). Poucas situações em que isso faz algum sentido:
Provavelmente haverá penalidades de desempenho, então, a menos que você tenha um bom motivo (como um dos acima), todo o espaço de qualquer disco que você queira dar a um btrfs deve ser dado a ele como um dispositivo. O btrfs em vários dispositivos faz mais sentido quando cada dispositivo está fisicamente em um disco separado.
Validação
Eu também não consigo ler o código-fonte. Baseio minhas alegações nas seguintes observações:
O fato de que antes da versão 4.5.1
mkfs.btrfs
só permitia que você usasse o DUP com um único dispositivo, e ainda assim você podia fazê-lo funcionar com vários dispositivos adicionando dispositivo(s) depoismkfs.btrfs
, é uma forte pista de que o DUP foi projetado para ser usado com um único dispositivo, mas não quebra as coisas quando usado com vários dispositivos. Eu encontrei esse fato emman 8 mkfs.btrfs
distribuído com btrfs-progs v6.2.Criei um arquivo regular esparso do tamanho de 1 GiB, criei um btrfs nele com
mkfs.btrfs -m dup -d single …
, montei sem compressão e enviei dados aleatórios para um arquivo dentro do sistema de arquivos (dd if=/dev/urandom …
) até que "não sobrasse espaço". Consegui armazenar 904 MiB de dados e o arquivo que contém o sistema de arquivos perdeu sua escassez em cerca de 904 MiB. Isso é esperado.Então comecei do zero e fiz isso com
-d dup
. Desta vez consegui armazenar 452 MiB, mas o arquivo que contém o sistema de arquivos perdeu sua escassez em cerca de 904 MiB, então o dobro. Isso indica que há "duplicação real" no caso de DUP em um único dispositivo.Similarmente, criei um arquivo regular esparso do tamanho de 1 GiB e outro arquivo regular esparso do tamanho de 400 MiB, criei um btrfs neles com
mkfs.btrfs -m dup -d single …
, montei sem compressão (precisei usarlosetup
duas vezes manualmente) e enviei dados aleatórios para um arquivo dentro do sistema de arquivos até que "não sobrasse espaço". Consegui armazenar 1263 MiB de dados. Os arquivos que continham o sistema de arquivos perderam sua escassez (agregada) como esperado.Em comparação com o caso acima de um único dispositivo
-d single
, o dispositivo adicional de 400 MiB me deu cerca de 359 MiB de espaço extra no sistema de arquivos.Então comecei do zero e fiz isso com
-d dup
. Dessa vez consegui armazenar 631 MiB. Os arquivos que continham o sistema de arquivos perderam sua escassez (agregada) em cerca de duas vezes mais.Em comparação com o caso acima de um único dispositivo
-d dup
, o dispositivo adicional de 400 MiB me deu cerca de 179 MiB de espaço extra no sistema de arquivos.Isso não só mostra que o DUP funciona em vários dispositivos, mas também que ele funciona como em um único dispositivo. Quero dizer, cópias redundantes podem ser alocadas para um dispositivo. No meu caso, alguns pedaços de dados tiveram que ser alocados para o dispositivo maior duas vezes, pois não há outra maneira de armazenar duas cópias de 631 MiB dentro de 1 GiB + 400 MiB.
Para comparação:
mkfs.btrfs -m raid1 -d raid1
em dois dispositivos (novamente 1 GiB + 400 MiB) me permitiu armazenar apenas 319 MiB. Ao contrário do DUP, o RAID1 força a alocação de cópias redundantes para dispositivos diferentes, então meu dispositivo de 400 MiB limitou a capacidade de todo o sistema de arquivos.Meu ambiente de teste foi o Debian 12, kernel 6.1.0, btrfs-progs v6.2.