O mais rápido sistema de arquivos do Linux em discos shingled

Question

Existe um interesse considerável em drives shingled. Eles colocam faixas de dados tão próximas que você não pode escrever em uma faixa sem danificar a próxima. Isso pode aumentar a capacidade em 20% ou mais, mas resulta em problemas de amplificação de gravação. Há trabalhos em andamento em sistemas de arquivos otimizados para unidades Shingled, por exemplo, consulte: link

Alguns discos shingled, como o arquivo Seagate 8TB, possuem uma área de cache para gravações aleatórias, permitindo um desempenho decente em sistemas de arquivos genéricos. O disco pode até ser bastante rápido em algumas cargas de trabalho comuns, até gravações redondas de 200MB / s. No entanto, é de se esperar que, se o cache de gravação aleatória estourar, o desempenho pode sofrer. Presumivelmente, alguns sistemas de arquivos são melhores para evitar gravações aleatórias em geral, ou padrões de gravações aleatórias com probabilidade de transbordar o cache de gravação encontrado nessas unidades.

Um sistema de arquivos mainstream no kernel do linux é melhor para evitar a penalidade de desempenho dos discos shingled do que o ext4?

    

Answer 1

Sistemas de arquivos intuitivamente Copy-on-Write e Log estruturados podem oferecer melhor desempenho em discos shingles, reduzindo a redução de gravações aleatórias. Os benchmarks suportam isso, no entanto, essas diferenças no desempenho não são específicas dos discos shingled. Eles também ocorrem em um disco não selecionado usado como controle. Assim, a mudança para um disco shingled pode não ter muita relevância para a escolha do sistema de arquivos.

O sistema de arquivos nilfs2 deu um bom desempenho no disco SMR. No entanto, isso foi porque eu aloquei toda a partição 8TB, e o benchmark só escreveu ~ 0.5TB para que o limpador nilfs não precisasse rodar. Quando limitei a partição a 200GB, os benchmarks do nilfs nem sequer foram concluídos com sucesso. Nilfs2 pode ser uma boa escolha em termos de desempenho se você realmente usar o disco "archive" como um disco de arquivamento onde você mantém todos os dados e instantâneos gravados no disco para sempre, então o nilfs cleaner não precisa ser executado.

Eu entendo que a unidade 8TB seagate ST8000AS0002-1NA17Z que usei para o teste tem uma área de cache ~ 20GB . Eu alterei as configurações padrão do fileserver filebench para que o conjunto de benchmarks fosse ~ 125GB, maior que a área de cache não-dimensionada:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Agora, para os dados reais. O número de ops mede o desempenho "geral" do servidor de arquivos, enquanto o ms / op mede a latência do acréscimo aleatório e pode ser usado como um guia aproximado para o desempenho de gravações aleatórias.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Como a Seagate tem 5980RPM, pode-se esperar ingenuamente que a Toshiba seja 20% mais rápida. Esses benchmarks mostram que ele é aproximadamente 3 vezes (200%) mais rápido, então esses benchmarks estão atingindo a penalidade de desempenho. Vemos que o disco Shingled (SMR) ainda não consegue igualar o desempenho do ext4 em um disco não-agrupado (PMR). O melhor desempenho foi com o nilfs2 com uma partição de 8TB (então o limpador não precisou ser executado), mas mesmo assim foi significativamente mais lento que o Toshiba com o ext4.

Para tornar os benchmarks acima mais claros, pode ser útil normalizá-los em relação ao desempenho do ext4 em cada disco:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

Vemos que no disco SMR o btrfs tem a maior vantagem em ops gerais que ele tem no ext4, mas a penalidade nos acréscimos aleatórios não é tão dramática quanto uma proporção. Isso pode levar alguém a mudar para o btrfs no disco SMR. Por outro lado, se você precisar de anexos aleatórios de baixa latência, este benchmark sugere que você deseja o xfs, especialmente no SMR. Vemos que, embora o SMR / PMR possa influenciar sua escolha do sistema de arquivos, considerando a carga de trabalho que você está otimizando, parece mais importante.

Eu também executei um benchmark baseado no sótão. As durações das corridas do sótão (nas partições de disco cheio de 8TB SMR) foram:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

Em cada caso, os repositórios do attic tinham as seguintes estatísticas:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

A adição de uma segunda cópia do mesmo disco de 1 TB ao sótão levou 4,5 horas em cada um desses três sistemas de arquivos. Um dump bruto dos benchmarks e smartctl information está em: link link

    

Answer 2

Se você rsync de uma unidade SMR, verifique se o sistema de arquivos está montado read-only ou com a opção noatime .

Caso contrário, a unidade SMR precisará gravar um registro de data e hora para cada arquivo que o rsync lê, resultando em uma degradação de desempenho significativa (de cerca de 80 mb / s para 3-5 mb / s aqui) e desgaste da cabeça / ruído de clique. / p>

Se você já tem um trabalho rsync sendo executado com desempenho ruim, não há necessidade de pará-lo, você pode remontar o sistema de arquivos de origem fazendo

sudo mount -o remount,ro  /path/to/source/fs

O efeito não será visto imediatamente, seja paciente e aguarde de 10 a 20 minutos, até que a unidade termine de gravar todos os dados ainda em seus buffers. Este conselho é testado e aprovado.

Isso também pode ser aplicado quando rsync para uma unidade SMR, ou seja, se o sistema de arquivos tentar atualizar o registro de data e hora após o arquivo ter sido totalmente gravado no disco. Essa tremenda carga de trabalho seqüencial e grandes faixas de dados são continuamente reescritas, contribuindo para o desgaste da unidade. Os seguintes podem ajudar:

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Isso precisa ser feito antes que o rsync seja executado; outros fatores podem tornar essa opção insignificante, ou seja, atualização FAT / MFT sem buffer, paraleliza gravações se o sistema de arquivos for otimizado principalmente para SSDs, etc.

Tente usar dd bs=32M e, em seguida, redimensione o sistema de arquivos no destino SMR, se quiser fazer backup de sistemas de arquivos completos (não é necessário montá-lo e executar o rsync para transportar cada arquivo neste caso).

O hardware real em uso era uma unidade de disco rígido gerenciada por disco SMR 8tb da Seagate. Sua milhagem pode variar com outro hardware.