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 exemplar em uso aqui era uma unidade de disco rígido gerenciada por disco SMR 8tb da Seagate. Sua milhagem pode variar com outro hardware.