Como isso pode ser?
A execução de um cp ou rsync (com -W --inplace) leva duas horas para 93 Gb; uma restauração em fita na rede de backup dedicada leva 41 minutos. A restauração da fita é de 50 Mb/s; disco para disco foi medido e calculado em 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 um array EMC Symmetrix por fibra. A caixa é um HP rx6600 (Itanium) com 16 Gb rodando HP-UX 11i v2. Todos os discos estão em uma placa de fibra, listada 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).
Atualizar:Ocorre-me que isso énãoapenas uma cópia direta de disco para disco; na realidade, é uminstantâneopara cópia do disco. A leitura do instantâneo poderia estar retardando tanto as coisas? O instantâneo é um instantâneo HP VxFS (não um vxsnap); talvez a interação entre o instantâneo e o VxVM esteja causando degradação da velocidade?
Atualizar:Usando fstyp -v, parece que o tamanho do bloco (f_bsize) é 8192; o tamanho de 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 cp; isso é intrigante: eu me pergunto.
Se o NetBackup estiver usando tar, então énãousando cp: isso também pode explicar o aumento da velocidade.
Atualizar:Parece que a leitura do instantâneo é quase duas vezes mais lenta que a leitura do dispositivo real. A execução do cp é lenta, assim como a gravação do tar na linha de comando. Usar tar é um pouco melhor (ao usar um arquivo), mas está limitado a arquivos de 8 Gb (o arquivo em questão tem cerca de 96 Gb). Usar File::Copy do perl com um volume que não seja de instantâneo parece ser uma das maneiras mais rápidas de fazer isso.
Vou tentar isso e conto aqui o que consegui.
Responder1
Outra questão é se você está vinculado ao IO dentro da rede FC, peça ao pessoal da SAN parademonstrar(os gráficos são bons)reallargura de banda sobressalente disponível (ah, e se os switches FC forem da Cisco, como eles estão garantindo que estão evitando problemas de largura de banda dentro do switch)
Responder2
Você está limitado a ler e gravar no mesmo disco da matriz?
Responder3
Se a sua fita também estiver na SAN, é possível que o xfer esteja sendo transferido e indo direto da fita para o disco, enquanto uma cópia precisa ser passada pelo host que está fazendo a cópia e, portanto, é mais lenta.
Responder4
Se os discos estiverem conectados a barramentos diferentes na placa-mãe, os dados poderão ser copiados em 3 ou mais barramentos internos e a latência estará matando seu IO para cópia de disco para disco. Neste caso, é inteiramente possível que a unidade de fita da rede tenha um caminho de largura de banda inerentemente maior para o disco de destino do que o disco de origem.