Qual é a diferença entre btrfs raid1 e btrfs -m dup -d dup em um único dispositivo

Question

Uso o btrfs há cerca de dois anos em vários dispositivos.

Estou planejando testar algumas configurações de btrfs em um HDD (prato único) que possui setores não confiáveis. Às vezes, uma dúzia de setores no HDD não são legíveis.

Haveria alguma diferença em termos de integridade de dados e velocidade geral de leitura e gravação nestas configurações:

1 TB HDD
-1 TB btrfs partition created with `mkfs.btrfs -d dup -m dup /dev/sda1`

1 TB HDD
-500 GB partition
-500 GB partition
--500 GB btrfs Raid 1 `mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sda2`

Answer 1

Eu sugeriria usar a variante em dupvez de colocar várias partições no mesmo dispositivo e invadi-las. A variante raid é ruim porque o raid solicita que ambas as cópias sejam lidas enquanto os dados são acessados ​​(isso é bom para raid normal de vários dispositivos porque se um dos dispositivos for mais rápido, os dados estarão disponíveis mais cedo). Com um dispositivo rotacional de dispositivo único, isso faz com que o cabeçote de leitura pule entre partições diferentes; portanto, se você tiver várias solicitações na fila (o caso usual), você terá um desempenho muito ruim. Aumentar a profundidade da fila e o agendador CFQ pode reduzir um pouco a latência geral, mas é melhor evitar essa bagunça.

A dupvariante deve ser sensata o suficiente para ler apenas uma cópia normalmente e apenas retornar para outra cópia se o setor não for legível.

Não tenho certeza sobre dupa implementação, mas acho que isso dupnão afasta o dispositivo de cópia 1/2 da primeira cópia, dupprovavelmente aumentando o desempenho de gravação também. Com invasão de dispositivo único, o desempenho de gravação também será ruim, porque uma operação lógica de gravação precisa ser gravada em dois locais no dispositivo rotacional físico e a diferença é sempre 1/2 dispositivo, então você acaba com um algoritmo que praticamente implementa o geral comportamento do pior caso para um dispositivo rotacional.

Answer 2

Posso pensar em uma diferença entre DUP e RAID1:

• Se você tem (como eu) alguns SSDs que quando não estão sendo usados ​​começam a dizer que setores aleatórios não são legíveis
• Então o DUP pode ser PANIC, já que um dos setores não legíveis no cabeçalho da partição BTRFS e o BTRFS não pode montar, ler, etc., nada armazenado nele. Enquanto estiver com o RAID1, você monta o outro (se não houver um desses setores não legíveis no outro cabeçalho da partição BTRFS) e faz uma limpeza para reescrever os setores não legíveis.
• RAID1 implica duas partições, cada uma com seu cabeçalho, portanto, se um cabeçalho for danificado (reformatar a partição) e o cabeçalho da outra partição estiver correto, você pode montar a outra partição e acessar o modo degradado e corrigi-lo (adicionar outra nova partição , exclua o que falta, equilibre no nível RAID1)

Agora minha história pessoal com os SSDs KingDian, que sofrem com a formação de setores aleatórios e não legíveis após um longo período de tempo (mais de oito dias) sem energia; e como o BTRFS RAID1 pode salvar e permitir o uso de tais SSDs (até uma colisão em setores não legíveis).

Primeiramente quero agradecer ao BTRFS e seu DUP (vou testá-lo em um futuro próximo) e RAID1 (já testado com resultados perfeitos); permitiu-me usar meus SSDs da marca KingDian. Para as marcas Yucun e Samsung ainda não vejo o problema de “setores não legíveis” que mostra todos os três SSDs da marca KingDian. Tenho em uso um total de 11 SSDs, um KingDian morreu, então só uso agora 10) e um SSD KingDian 1TiB que estou com medo de começar a usar (estava planejando usá-lo em FAT32 ou NTFS para reprodução de TV legalmente compre DVDs convertidos para H.264/2xAAC).

O problema com os SSDs KingDian é muito estranho, então vou contar o que faço passo a passo para ver o problema:

1. Crie uma partição de apenas 90% e formate-a, até alguns dias atrás eu usava Ext4 (Linux) / NTFS (partição de sistema Windows); eu realmente odeio o Windows, mas sou forçado a usá-lo.
2. Instale o sistema nessa partição
3. Use o sistema todos os dias -> Nenhum problema mostrado
4. Desligue e deixe-o desligado por mais de oito dias -> O problema aparece nos SSs KingDian
5. Para ver o problema eu inicializo com uma distribuição Live Linux (DVD / USB / etc), eu uso principalmente SystemRescueCD, mas qualquer outro que tenha "ntfsclone" / "partclone.*" / "partimage" ou apenas um "dd" simples irá servir
6. Eu faço um clone da partição salvando como um arquivo (como salvar a partição do sistema na mídia BackUp)
7. O problema aparece, existem alguns setores (entre alguns até perto de 25 ou 30) que não são legíveis
8. Anoto (em um papel) quais setores não são legíveis
9. Agora começa a coisa estranha, eu desligo corretamente e deixo desligado por mais oito ou mais dias
10. Repito os passos 4 a 7 para ver quais setores agora não estão legíveis, a lista muda muito, na maioria das vezes ambas as listas não tem ninguém em comum, então todos os setores não legíveis tornaram-se legíveis e outros que eram legíveis agora não são legíveis
11. Posso repetir isso muitas vezes (sem nenhuma gravação no SSD) e todas as listas de setores não legíveis tendem a não ter nenhum setor em comum (às vezes um está em duas listas)

Por que esses SSDs (apenas com a marca KingDian) fazem coisas tão feias e estranhas? dizem aleatoriamente que alguns setores não são legíveis após um longo período (mais de oito dias) sem fonte de alimentação, e após outro período (mais de oito dias) sem fonte de alimentação eles se tornaram legíveis novamente.

O mais estranho é que depois de ficarem ilegíveis e tornarem-se legíveis novamente, todos eles sempre terão os dados corretos.

Além disso, consulto dados SMART e diz que não há nenhum novo setor realocado (tem alguns porque uma vez usei no Windows uma ferramenta para forçar a realocação de setor não legível).

A informação SMART também diz que não há erro de leitura, enquanto alguns setores não são legíveis, e também diz que não há erro de gravação.

Obviamente não há erro de "leitura", nada "lido" com dados "errados"... isso é tecnicamente diferente de não ter sido capaz de ler... e os dados SMART não têm nenhum campo que eu possa ver que mostre uma contagem de erros não legível ... etc.

A propósito, se eu reescrever setores não legíveis com dados, eles se tornarão legíveis novamente sem que nenhum setor tenha sido remapeado, talvez porque os internos usados ​​não sejam os que falham (lembre-se de que o SSD nas gravações usa locais diferentes para estender ao vivo, o SSD usa um mapa interno LBA - Posição real dentro dos chips).

A propósito, clonar uma partição com 30GiB de dados e sem esse problema levou apenas menos de um minuto (o SSD pode ler a 550MiB/s sustentados durante a clonagem da partição, também conhecida como leituras sequenciais); mas com 25 setores não legíveis demorou mais de 24 horas (ignorando tais erros ou então não acaba) e terá alguns dados "corrompidos" (aquele que não pôde ser lido).

É aqui que o BTRFS veio me salvar:

• Primeiramente eu estava usando duas partições no mesmo SSD no nível RAID1 de BTRFS para DADOS e METADATOS
• Agora que sei sobre DUP em vez de RAID1, testarei com DUP; e isso me permitirá evitar executar backup de duas partições clones de cada vez, apenas uma; isso seria ótimo (funciona)

Como foi me salvar? Fácil: Antes de fazer um clone na mídia BackUP, eu limpo o que desejo clonar para que os setores não legíveis façam com que o BTRFS os substitua pela outra cópia (esperando que não haja nenhum setor não legível para ambas as cópias no mesmo tempo e mesma posição).

Com duas partições funcionou bem (lento, mas funcionou) e não perdeu alguns setores nos dados clonados; agora devo testar com DUP em uma partição em vez de RAID1 em duas partições de tamanho idêntico.

Isso não reduz o tempo de fazer o BackUP (também a limpeza leva um tempo extra), mas pelo menos posso ter certeza de que todos os dados estão corretos... até que um dia dois setores não legíveis ocorrem para os mesmos dados (colisão) no mesma posição ao mesmo tempo, isso será irrecuperável.

A outra opção é óbvia: não usar mais nenhum SSD KingDian, que até agora são os únicos que usei que apresentam esse problema (setores não legíveis após longos períodos sem energia).

Imagine que você saiu de férias, cortou a energia geral da casa, voltou e seus SSDs estão com porções ilegíveis!!! Grande problema para usuários domésticos, não para datacenters onde os SSDs estão sempre ligados.

Ótimo BTRFS!!! Agora pense na outra parte feia (para mim), como fazer algo semelhante para a partição NTFS (partição de sistema Windows)? De jeito nenhum, o NTFS não tem essa opção (lembre-se das versões do Windows HOME, não dos SERVIDORES, etc.).

Então, obrigado BTRFS, o Linux é muito melhor do que eu pensava há alguns dias... sou um usuário do Linux há décadas... mas me recusei a tentar o BTRFS porque todas as informações RUIM sobre corrupção total, etc .; até encontrar um problema de SSD e precisar de algo com redundância.

A outra opção que eu estava pensando era o ZFS, muito mais complicado, não integrado no bootloader GRUB2, não integrado no Kernel (e talvez nunca seja por causa do sistema de licenciamento), etc.; então eu tentei (ontem) BTRFS... e que surpresa, parece muito estável, relativamente fácil de usar (aviso ao adicionar um novo disco, ele adiciona em RAID0, não em RAID1, eu não uso RAID5/6/ etc, nem quero usá-los), fácil de recuperar de danos catastróficos (reformatar uma das duas partições) sem perda de dados (em SSDs que não sejam KingDian), etc.

É claro que não uso subvolumes, snapshots, etc... apenas como um sistema de arquivos simples para raiz "/" do Linux no RAID1; como eu disse, devo testar com DUP em vez de RAID1, mas tenho medo (sou muito paranóico) de ficar com DUAS partições no mesmo SSD em RAID1, já que o setor não legível no cabeçalho da partição implicará que todos os BTRFS não serão recuperáveis /legível.

Se eu ainda conseguir ver o SSD KingDian entre eles que apresentam setores aleatoriamente não legíveis, seria uma economia de dinheiro, os SSDs não são baratos, pois eu só quero usar SSDs de célula de um bit e isso é muito caro, mais conforme o tamanho aumenta (eu digo que sou muito paranóico) e tenho mais de 10 cópias de backup off-line de todos os dados com histórico de mais de cem últimos estados (muito paranóico, eu sei).

Answer 3

Encontrei pelo menos uma diferença:

Você pode montar seu raid1 rw degradado apenas uma vez. A chance de falha de uma partição enquanto outra partição do seu dispositivo está íntegra pode ser pequena, mas isso é uma diferença.

Fonte: https://btrfs.wiki.kernel.org/index.php/Gotchas#raid1_volumes_only_mountable_once_RW_if_degraded

Volumes raid1 montáveis ​​apenas uma vez RW se degradados

Mesmo que não haja pedaços de perfil únicos, os volumes raid1, se ficarem degradados, só poderão ser montados para leitura e gravação uma vez com as opções -o degradado,rw.

Notas:

• Isso não acontece (supostamente) quando há mais de 2 dispositivos.

• Isso não acontece com volumes de perfil raid10.

• Isso geralmente ocorre devido ao problema de "Conversão de pedaços incompletos", onde restam pedaços únicos.

Possíveis recuperações:

• Se ainda for leitura e gravação, você poderá converter os pedaços do perfil raid1 para perfil único (ou perfil dup) se tiver espaço suficiente).

• Se ainda for leitura e gravação, você poderá substituir o dispositivo btrfs pelo dispositivo ausente.

• Quando um volume raid1 fica travado como somente leitura por qualquer motivo, ele só pode ser recuperado despejando seu conteúdo, recriando-o e restaurando-o.

Answer 4

Atrasado para a festa, mas enfim. Eu estava pensando sobre a mesma pergunta e no homem que li (sobre dup):

"Por exemplo, uma unidade SSD pode remapear os blocos internamente para uma única cópia, desduplicando-os. Isso anula o propósito de aumentar a redundância (sic) e apenas desperdiça espaço"

Talvez o raid1 fosse uma forma de evitar essa preocupação (ou não).