Por que o desempenho do zfs seria ruim para mover arquivos dentro de um fs?

4

No meu NAS FreeNAS (9.1.1 rodando o zfs v28), estou obtendo um desempenho terrível para movimentações de arquivos entre dois diretórios no mesmo raidz fs. Isso é esperado? Como posso encontrar esse erro, se não?

O aplicativo neste caso é o Beets (software mp3 mgmt), executado em uma cadeia no próprio NAS, portanto, não é um caso de desempenho do CIFS ou problemas de rede - os dados não saem do servidor. Tudo o que o software está fazendo é renomear em um diretório diferente, mas o desempenho é como se estivesse copiando todos os dados.

O sistema não está sob nenhuma carga específica. Eu realmente parei os outros processos em execução no servidor apenas para liberar alguma memória e CPU, apenas no caso.

Atualizado: Os dois diretórios estão no mesmo ponto de montagem dentro da cadeia. A piscina é de 4 unidades de 2 TB SATA em um raidz1. Nenhuma desduplicação ou compactação.

Atualizado 2: desabilitar o atime no fs também não faz diferença (acho que eu também posso tentar).

Atualização 3: saída do zfs / zpool.

[root@Stillmatic2] ~# zpool status
  pool: jumbo1
 state: ONLINE
  scan: scrub repaired 0 in 95h19m with 0 errors on Wed Jul 16 23:20:06 2014
config:

        NAME        STATE     READ WRITE CKSUM
        jumbo1      ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada0    ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0

errors: No known data errors

[root@Stillmatic2] ~# zfs list
NAME                                                         USED  AVAIL  REFER  MOUNTPOINT
jumbo1                                                      5.32T  21.4G  40.4K  /mnt/jumbo1
jumbo1/data                                                 76.0G  21.4G  76.0G  /mnt/jumbo1/data
jumbo1/howie                                                2.03G  21.4G  2.03G  /mnt/jumbo1/howie
jumbo1/jails                                                45.1G  21.4G   139M  /mnt/jumbo1/jails
jumbo1/jails/.warden-template-9.1-RELEASE-amd64              347M  21.4G   347M  /mnt/jumbo1/jails/.warden-template-9.1-RELEASE-amd64
jumbo1/jails/.warden-template-9.1-RELEASE-amd64-pluginjail   853M  21.4G   852M  /mnt/jumbo1/jails/.warden-template-9.1-RELEASE-amd64-pluginjail
jumbo1/jails/hj-tools                                       43.8G  21.4G  44.1G  /mnt/jumbo1/jails/hj-tools
jumbo1/movies                                               1.56T  21.4G  1.56T  /mnt/jumbo1/movies
jumbo1/music                                                1.45T  21.4G  1.45T  /mnt/jumbo1/music
jumbo1/tv                                                   2.19T  21.4G  2.19T  /mnt/jumbo1/tv
    
por AnotherHowie 11.08.2014 / 16:10

1 resposta

5

21 GB de ~ 6 TB disponíveis = > < 1% de espaço livre. A ZFS recomenda 20% de espaço livre para o RAIDZ, e pelo menos 10% é principalmente obrigatório para qualquer desempenho razoável. Você precisa liberar algum espaço ou expandir o tamanho da matriz.

Nós secundários:

    As unidades SATA precisam ser limpas semanalmente se você espera detectar falhas de matriz antes de entrar no provável perda de dados . Parece que faz um mês desde o último banho.
  1. Você provavelmente ainda está na porcentagem inteira de chances de falha na matriz ao ser reconstruída devido à maneira como isso funciona. Veja O que conta como uma 'grande' raid 5 array? para detalhes.
por 11.08.2014 / 23:38