Sistema de arquivos Linux mais rápido em discos shingled

Há um interesse considerável em unidades shingled. Eles colocam as faixas de dados tão próximas que você não pode gravar em uma faixa sem perder a próxima. Isso pode aumentar a capacidade em cerca de 20%, mas resulta em problemas de amplificação de gravação. Há trabalho em andamento nos sistemas de arquivos otimizados para unidades Shingled, por exemplo, consulte: https://lwn.net/Articles/591782/

Alguns discos shingled, como o arquivo da Seagate 8TB, têm 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, com gravações de até 200 MB / s. No entanto, é de esperar que se o cache de gravação aleatória exceder o limite, o desempenho poderá sofrer. Presumivelmente, alguns sistemas de arquivos são melhores em evitar gravações aleatórias em geral ou padrões de gravações aleatórias que provavelmente excederão o cache de gravação encontrado nessas unidades.

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

Os sistemas de arquivos estruturados Copiar na Gravação e Log Intuitivamente podem oferecer melhor desempenho em discos shingled, reduzindo reduções aleatórias de gravação. Os benchmarks suportam um pouco isso, no entanto, essas diferenças no desempenho não são específicas para discos shingled. Eles também ocorrem em um disco sem shingled usado como controle. Portanto, a mudança para um disco com shingled pode não ter muita relevância para a sua escolha do sistema de arquivos.

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

Entendo que a ST8000AS0002-1NA17Zunidade seagate de 8 TB que usei para o teste possui uma área de cache de ~ 20 GB . Alterei as configurações padrão do servidor de arquivos do banco de arquivos para que os parâmetros de referência fossem ~ 125 GB, maiores que a área de cache sem shingled:

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

Agora, para os dados reais. O número de operações mede o desempenho "geral" do servidor de arquivos enquanto o ms / op mede a latência do anexo 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 o Seagate é 5980RPM, pode-se esperar ingenuamente que o Toshiba seja 20% mais rápido. Esses benchmarks mostram que é aproximadamente três vezes (200%) mais rápido, portanto, esses benchmarks estão atingindo a penalidade de desempenho. Vemos que o disco com shingled (SMR) ainda não pode corresponder ao desempenho ext4 em um disco sem shingled (PMR). O melhor desempenho foi com o nilfs2 com uma partição de 8 TB (portanto, o limpador não precisava ser executado), mas mesmo assim foi significativamente mais lento que o Toshiba com o ext4.

Para tornar os benchmarks acima mais claros, pode ser 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

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

Também executei um benchmark baseado no sótão. As durações das execuções no sótão (nas partições de disco completo de 8 TB 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 sótão 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 despejo bruto dos benchmarks e smartctlinformações está em: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Se você é rsync de uma unidade SMR, verifique se o sistema de arquivos está montado read-onlyou com noatimeopção.

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 significativa do desempenho (de cerca de 80 mb / s para 3-5 mb / s aqui) e ruído na cabeça / clique.

Se você já tem um trabalho rsync em execução com desempenho fraco, não há necessidade de interrompê-lo, é possível remontar o sistema de arquivos de origem executando

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

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

Isso também pode se aplicar quando rsyncing para uma unidade SMR, ou seja, se o sistema de arquivos tenta atualizar o timestamp após o arquivo foi totalmente gravado em disco. Essa carga de trabalho seqüencial e grande quantidade de dados são reescritas continuamente, contribuindo para aumentar o desgaste. O seguinte pode 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 sem buffer de FAT / MFT, gravações paralelas se o sistema de arquivos for otimizado principalmente para SSDs, etc.

Tente usar dd bs=32Me redimensionar o sistema de arquivos no destino SMR, se você quiser fazer backup de sistemas de arquivos completos de qualquer maneira (não é necessário montá-lo e executar o rsync para transportar todos os arquivos nesse caso).

O hardware real em uso era uma unidade consumidora SMR de 8 TB gerenciada pela Seagate. Sua milhagem pode variar com outro hardware.