Compreendendo o comportamento de uso de metadados em um sistema de arquivos btrfs recentemente convertido

3

Eu tenho um disco rígido de 5 TB com 3.3 TiB (conforme relatado por du ) de arquivos de mídia em arquivos e diretórios de 119k; o tamanho médio do arquivo era de cerca de 28 MiB. Eu converti a partição ext4 em btrfs com btrfs-convert . O processo levou 10,4 horas e estava ligado à CPU. Logo após a conversão:

# btrfs fi df /mnt/btrfs/
Data, single: total=3.03TiB, used=2.21TiB
System, single: total=32.00MiB, used=236.00KiB
Metadata, single: total=1.52TiB, used=1.10TiB

btrfs alocou todo o espaço no disco rígido (3.03 + 1.52 TiB ≈ 5 TB), e aparentemente colocou ~ 1 TiB de conteúdo de arquivo em pedaços de metadados (1.10 TiB usados). Isso é inesperado porque muito poucos dos meus arquivos se encaixam nos nós da folha.

A solução padrão para a enorme alocação de metadados é reequilibrar os metadados. btrfs balance start -m demorou 8,0 horas e estava vinculado a E / S. Posteriormente, parece que o btrfs não apenas liberou fragmentos de metadados não usados, mas também moveu o conteúdo de arquivos de fragmentos de metadados para blocos de dados.

# btrfs fi df /mnt/btrfs/
Data, single: total=3.32TiB, used=3.31TiB
System, single: total=32.00MiB, used=104.00KiB
Metadata, single: total=3.00GiB, used=2.18GiB

Alguém poderia explicar o que está acontecendo? Por que os "metadados" consumiriam 1,10 TiB inicialmente e por que o balanceamento reduziria para 2,18 GiB? O btrfs balance move o conteúdo do arquivo de fragmentos de metadados para blocos de dados?

Eu usei o kernel Linux 3.13.0-46. Meus arquivos não possuem links físicos, xattrs, contextos SELinux nem ACLs. Não ativei a compactação e não excluí a imagem de retrocesso do ext4.

    
por netvope 16.03.2015 / 08:29

1 resposta

1

Primeiro, o processo de conversão salva uma cópia de todos os metadados anteriores do sistema nos novos metadados, o que pode ocupar uma quantidade substancial de espaço em unidades grandes.

Segundo, o processo de conversão é confuso, resultando em extensões extremamente grandes, já que as extensões no EXT4 também são grandes, e o BTRFS irá herdar seu tamanho.

O tamanho alocado se torna aproximadamente 1,5X o tamanho do tamanho de metadados usado. O processo de desfragmentação reduzirá o tamanho dos metadados usados, mas não altera a alocação. Há também uma opção de extensões skinny para reduzir ainda mais os metadados, mas isso é mais útil em sistemas com grandes quantidades de arquivos pequenos; sua alocação de metadados menor que 10% de um percentual, o que é muito pequeno.

O comando de equilíbrio deve reduzir o tamanho da alocação para um novo valor com base no uso atual de metadados, o que parece ter sido feito corretamente. O comando balance não deve passar de metadados para dados, mas isso pode ter algo a ver com a cópia da imagem de metadados EXT4 original que está na alocação de metadados original e agora é movida para dados (subvolume ext2_saved). Verifique o tamanho da imagem EXT4 para ver se é 1.1TB. Independentemente disso, eu desfragmentaria o sistema de arquivos.

Deve-se observar que executar o equilíbrio sem desfragmentação pode resultar em erros. Versões mais recentes do kernel são recomendadas para evitar problemas no sistema de arquivos, especificamente 3.17 e posteriores.

    
por 29.04.2015 / 04:14