Por que meus sistemas de arquivos XFS estão subitamente consumindo mais espaço e arquivos esparsos?

58

Eu executei sistemas de arquivos XFS como partições de dados / crescimento por quase 10 anos em vários servidores Linux.

Eu notei um fenômeno estranho com servidores CentOS / RHEL recentes executando a versão 6.2+.

O uso estável do sistema de arquivos tornou-se altamente variável após a mudança para a revisão mais recente do sistema operacional a partir do EL6.0 e do EL6.1. Os sistemas inicialmente instalados com EL6.2 + exibem o mesmo comportamento; mostrando oscilações selvagens na utilização do disco nas partições XFS (veja a linha azul no gráfico abaixo).

Antes e depois. A atualização de 6.1 para 6.2 ocorreu no sábado.

Ográficodeusodediscodoúltimotrimestredomesmosistema,mostrandoasflutuaçõesnaúltimasemana.

Eucomeceiaverificarossistemasdearquivosparaarquivosgrandeseprocessosdefuga(arquivosdelog,talvez?).Descobriquemeusmaioresarquivosrelatavamvaloresdiferentesdeduels.Aexecuçãodeducomesemaopção--apparent-sizeilustraadiferença.

#du-skhSOD0005.TXT29GSOD0005.TXT#du-skh--apparent-sizeSOD0005.TXT21GSOD0005.TXT

Umarápidaverificaçãousandoo utilitário ncdu em todo o sistema de arquivos resultou:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

O sistema de arquivos está cheio de arquivos esparsos , com quase 70GB de espaço perdido em comparação com a versão anterior do OS / kernel!

Analisei o Red Hat Bugzilla e mudei os logs para ver se havia algum relato do mesmo comportamento ou novos anúncios sobre o XFS .

Nada.

Eu fui da versão do kernel 2.6.32-131.17.1.el6 para 2.6.32-220.23.1.el6 durante a atualização; nenhuma alteração no número da versão secundária.

Eu verifiquei a fragmentação de arquivos com a ferramenta filefrag . Alguns dos maiores arquivos da partição XFS tinham milhares de extensões. A execução da desfragmentação online com xfs_fsr -v durante um período lento de atividade ajudou a reduzir o uso do disco temporariamente (consulte a quarta-feira no primeiro gráfico acima). No entanto, o uso aumentou quando a atividade pesada do sistema foi retomada.

O que está acontecendo aqui?

    
por ewwhite 09.07.2012 / 17:27

1 resposta

72

Eu rastreei esse problema para uma discussão sobre um commit na árvore de código-fonte do XFS a partir de dezembro de 2010. O patch foi introduzido no Kernel 2.6.38 (e, obviamente, mais tarde backported em alguns kernels populares de distribuição Linux).

As flutuações observadas no uso do disco são resultado de um novo recurso; Preallocation de EOF especulativo dinâmico do XFS .

Esta é uma ação para reduzir a fragmentação de arquivos durante as gravações de fluxo, alocando especulativamente o espaço à medida que o tamanho dos arquivos aumenta. A quantidade de espaço pré-alocada por arquivo é dinâmica e é basicamente uma função do espaço livre disponível no sistema de arquivos (para evitar a falta total de espaço).

Segue esse cronograma:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

Esta é uma adição interessante ao sistema de arquivos, pois pode ajudar com alguns dos arquivos massivamente fragmentados que eu lido.

O espaço adicional pode ser recuperado temporariamente liberando o pagecache, dentries e inodes com:

sync; echo 3 > /proc/sys/vm/drop_caches

O recurso pode ser desativado totalmente definindo um valor allocsize durante a montagem do sistema de arquivos. O padrão para o XFS é allocsize=64k .

O impacto dessa mudança provavelmente será sentido pelos sistemas de monitoramento / limiar (que é como eu peguei), mas também afetou sistemas de banco de dados e podem causar resultados imprevisíveis ou indesejados para máquinas virtuais com thin provisioning e storage arrays (eles usarão mais espaço do que o esperado).

Em suma, ele me pegou de surpresa porque não havia nenhum anúncio claro da mudança no sistema de arquivos no nível da distribuição ou até mesmo no monitoramento do Lista de discussão XFS .

Editar :
O desempenho em volumes XFS com esse recurso foi drasticamente melhorado. Estou vendo consistente < 1% de fragmentação em volumes que anteriormente exibiam até 50% de fragmentação. O desempenho de gravação está em alta globalmente!

Estatísticas do mesmo conjunto de dados, comparando o XFS herdado com a versão no EL6.3.

Antigo:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Novo:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%
    
por 09.07.2012 / 17:27