BTRFS saldo concluído, mas ainda mostra dados armazenados no modo "único"

2

Eu tenho três drives (8TB, 4TB, 3TB). Originalmente, criei uma partição btrfs na unidade de 8 TB e copiei todos os meus dados lá. Adicionei as unidades de 4 TB e 3 TB usando o dispositivo btrfs add e, em seguida, executei uma conversão de saldo:

btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt

Agora a balança está pronta, mas ainda mostra alguns dados no modo "single" e "DUP" na unidade original. Aqui está a saída de btrfs fi usage /mnt/btrfs :

Overall:
    Device size:          13.37TiB
    Device allocated:          4.62TiB
    Device unallocated:        8.75TiB
    Device missing:          0.00B
    Used:              4.60TiB
    Free (estimated):          4.98TiB  (min: 4.38TiB)
    Data ratio:               1.76
    Metadata ratio:           2.00
    Global reserve:      512.00MiB  (used: 0.00B)

Data,single: Size:645.00GiB, Used:645.00GiB
   /dev/mapper/8TB   645.00GiB

Data,RAID1: Size:1.98TiB, Used:1.98TiB
   /dev/mapper/3TB   551.00GiB
   /dev/mapper/4TB     1.44TiB
   /dev/mapper/8TB     1.98TiB

Metadata,RAID1: Size:8.00GiB, Used:3.84GiB
   /dev/mapper/4TB     8.00GiB
   /dev/mapper/8TB     8.00GiB

Metadata,DUP: Size:7.00GiB, Used:6.41GiB
   /dev/mapper/8TB    14.00GiB

System,DUP: Size:8.00MiB, Used:400.00KiB
   /dev/mapper/8TB    16.00MiB

Unallocated:
   /dev/mapper/3TB     2.19TiB
   /dev/mapper/4TB     2.19TiB
   /dev/mapper/Seagate_Archive_8TB-btrfs       4.37TiB

Perguntas:

  1. Existe algum dado que não está armazenado em mais de um disco? Então, em outras palavras, há algum dado que seria perdido se um disco falhasse? Se sim, como posso coagir esses dados "únicos" remanescentes armazenados no RAID1?
  2. Assumindo que os armazenamentos de dados "single" e "DUP" são desnecessários, agora que tudo foi convertido em raid, existe alguma maneira de limpá-los?

Editar: aqui estão algumas informações do sistema:

uname -a 
Linux 4.8.0-0.bpo.2-amd64 #1 SMP Debian 4.8.11-1~bpo8+1 (2016-12-14) x86_64 GNU/Linux
btrfs --version
btrfs-progs v4.9

Eu também devo mencionar que este computador foi reiniciado durante a balança, e quando ele voltou, eu não consegui montar o volume do btrfs (ele simplesmente seria interrompido). Eu tentei com vários parâmetros de montagem diferentes (skip-param, recovery) e o único que funcionava era montá-lo somente para leitura (usando -o ro ). Depois de muita frustração, eu inicializei com um Antergos live USB, que tinha o kernel mais novo e o btrfs progs nele, e ele montava sem nenhum problema. Eu pausei a operação de balanceamento que tinha sido iniciada automaticamente e então inicializei de volta no Debian, e ela montou sem um problema, então eu retomei o equilíbrio novamente.

    
por process91 12.01.2017 / 17:20

1 resposta

2

Com a ajuda de um usuário no btrfs irc, pude responder à pergunta (1). Parece não ter relação com a reinicialização e tentativa de montagem malsucedida (ainda não tenho certeza do que se tratava). Em vez disso, parece que os 645 GB de dados armazenados como "únicos" eram dados que foram adicionados ao volume btrfs após a conversão de raid1 ter sido iniciada. Portanto, parece uma boa prática verificar a saída de btrfs fi usage antes de assumir que todos os seus dados são armazenados como raid1 após uma conversão. Além disso, o filtro "soft" permitirá que você reequilibre os dados que não estão sendo armazenados de acordo com o perfil de destino. Por exemplo, eu corri:

btrfs balance start --bg -mconvert=raid1,soft /mnt/btrfs
btrfs balance start --bg -dconvert=raid1,soft /mnt/btrfs

(seguindo uma sugestão do usuário no fórum btrfs irc para executar o saldo nos metadados primeiro e depois nos dados) e isso está no processo de converter os dados restantes para o raid1.

Além disso, para responder à pergunta (2), a resposta é que é possível acabar com alguns fragmentos "únicos" em um sistema de arquivos raid1, mas eles devem ter 0 uso. Se isso acontecer, você pode limpá-los executando

btrfs balance start -dusage=0 -musage=0 /mnt/btrfs

(veja a FAQ do btrfs )

    
por 15.01.2017 / 06:56