Como isso pode ser?
A execução de um cp ou rsync (com -W --inplace) leva duas horas para 93Gb; uma restauração de fita na rede de backup dedicada é de 41 minutos. A restauração de fita é de 50 Mb / s; disco para disco foi medido e calculado como sendo 16 Mb / s no máximo - 2 Mb / s se a CPU estiver ocupada.
O software de restauração é o Veritas NetBackup; os discos estão em uma matriz EMC Symmetrix sobre fibra. A caixa é um HP rx6600 (Itanium) com 16 Gb executando o HP-UX 11i v2. Todos os discos estão em um cartão de fibra, listados como:
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
Os discos também usam o Veritas Volume Manager (em vez do HP LVM).
Atualização: Ocorre-me que isso não é apenas uma cópia de disco para disco; na realidade, é um snapshot para a cópia do disco. Poderia ler o instantâneo diminuir tanto as coisas? O instantâneo é um instantâneo do HP VxFS (não um vxsnap); talvez a interação entre a captura instantânea e o VxVM esteja causando degradação de velocidade?
Atualização: Usando fstyp -v, parece que o tamanho do bloco (f_bsize) é 8192; o tamanho do bloco padrão do UNIX é 512 (ou 8192/16). Ao testar com dd, usei um tamanho de bloco de 1024k (ou 1048576 ou 8192 * 128).
Eu realmente me pergunto se é o tamanho do bloco. Eu li no PerlMonks que o módulo Perl File :: Copy é mais rápido que o cp; isso é intrigante: eu me pergunto.
Se o NetBackup estiver usando o tar, então não será usado o cp: isso também pode explicar o aumento de velocidade.
Atualização: Parece que a leitura do instantâneo é quase duas vezes mais lenta do que a leitura do dispositivo real. A execução do cp é lenta, assim como o tar é escrito na linha de comando. O uso do tar é um pouco melhor (ao usar um arquivo), mas é limitado a arquivos de 8 Gb (o arquivo em questão é 96Gb ou mais). Usar File :: Copy do perl com um volume não instantâneo parece ser uma das maneiras mais rápidas de ir.
Vou tentar isso e vou relatar aqui o que recebo.
Outra pergunta é se você está com E / S dentro da rede FC, peça aos caras da SAN para demonstrar (gráficos são bons) real largura de banda disponível (oh, e se os switches FC são da Cisco, como eles estão garantindo que estão evitando os problemas de largura de banda dentro do switch)
Você está limitado lendo e gravando no mesmo disco da matriz?
Se a sua fita também estiver na SAN, então é possível que o xfer esteja sendo passado e direto da fita para o disco, enquanto uma cópia está sendo passada para passar pelo host que está fazendo a cópia e, portanto, é mais lenta .
Para garantir que seu teste seja parecido, tente fazer a cópia do disco via tar (o NetBackup usa o tar para ler da fita):
$ tar cf - oldstuff | (cd newdir; tar xf -)
Se todos os seus discos estiverem no mesmo cartão de fibra, você poderia teoricamente ser E / S ligado a esse cartão, mas duvido.
O instantâneo do VxFS pode estar adicionando sobrecarga, especialmente se o sistema de arquivos de origem original estiver ocupado com gravações no momento. O VxFS copia na gravação, portanto, se o disco original estiver recebendo gravações, os discos de instantâneos estarão ocupados recebendo os dados do disco original.
Se o sistema de arquivos original estiver ocioso, você pode excluir o fato de o VxFS ser um fator.
Se os discos estiverem conectados a diferentes barramentos na placa-mãe, os dados poderão ser copiados em 3 ou mais barramentos internos e a latência estará eliminando seu IO para a cópia de disco para disco. Nesse caso, é totalmente possível que a unidade de fita de rede tenha um caminho de largura de banda inerentemente maior para o disco de destino do que o disco de origem.