Eu tenho uma máquina Debian na minha LAN servindo como um servidor de backup para os outros. Ele tem quatro HDDs combinados em um dispositivo de software RAID 5 md, em que um LVM, e nesse btrfs. Os backups são feitos usando o rsync e, para um sistema de arquivos grande, levam mais de uma hora. Por muito tempo eu pensei que haveria pouco a fazer sobre isso.
Recentemente, no entanto, notei que a atividade do HDD era muito diferente nos dois extremos da transferência. Enquanto o lado de envio, rodando o Gentoo e usando principalmente o ext4, tinha praticamente nenhum disco IO, o lado receptor estava constantemente ocupado. Como a maioria dos dados não mudaria entre as transferências, acredito que as leituras de metadados devem compor a maior parte dos dados. Mas eu ficaria muito surpreso se ler inodes no btrfs é muito mais trabalhoso do que fazer o mesmo no ext4.
iotop confirmou leituras de disco de cerca de 1-4 MB / s no lado de recebimento, enquanto o lado de envio teve apenas o estouro de 0,5 MB / s ocasionalmente.
Minha pergunta é: alguém pode explicar o que está acontecendo aqui? De preferência, com alguma indicação de como resolver o problema, se possível.
Talvez haja algum sinalizador de btrfs que eu possa usar ou algo similar. Eu preciso de um FS com recursos de snapshots no servidor de backup, e minha tentativa de usar o FreeBSD e o ZFS rapidamente leva a um FS inconsistente, então vejo pouca alternativa para o btrfs no momento. Portanto, as respostas que me dizem para usar ext4 ou zfs podem receber votos positivos, mas não marcar.
Opções de rsync em uso, conforme solicitado por cjm :
--rsync-path='rsync --fake-super'
--archive # -rlptgoD
--hard-links # detect and preserve these
--acls
--xattrs
--sparse
--noatime # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable # size suffixes, base 1000
--stats
Assim como um monte de regras -f para omitir alguns arquivos.
As opções de montagem do btrfs são relatadas por mount as
rw,nosuid,noexec,noatime,nospace_cache
Em particular, isso inclui o sinal noatime , portanto, não deve haver nenhum documento envolvido, a menos que haja diferenças em alguns arquivos. Eu adicionei esta informação em resposta à resposta por Kyle Jones .
Uma resposta possível é que o sistema de arquivos remoto é montado por padrão com a opção "atime". O tempo de acesso gravado para tudo o que o rsync remoto acessa combinado com a penalidade de gravação que você sofre com o RAID 5 (paridade de computação significa ler todos os discos RAID antes de gravar em um deles) poderia explicar a ampliação de E / S no lado remoto. / p>
Se eu estiver certo, você pode acelerar as coisas montando o sistema de arquivos remoto com a opção "noatime".
Eu suspeito que as opções --fake-super. Isso diz ao rsync para armazenar todas as informações de metadados em atributos estendidos em cada arquivo. Eu suspeito que acessar esses atributos é lento. Tente um teste com o rsync para uma raiz sem --fake-super. Você não pode reutilizar o mesmo backup, pois os atributos não serão correspondentes.
Tags performance rsync btrfs mdadm io