Conforme pergunta acima, o 7zip (mais especificamente o p7zip no Linux) usa espaço em disco ao testar arquivos? Como só tenho uma unidade de 2 TB para trabalhar e com cada arquivo variando de 800 GB a 1 TB, estava pensando em testar 2 arquivos ao mesmo tempo, em vez de apenas um.
A documentação oficial do 7zip não menciona o uso do disco durante o teste.
Responder1
Não deveria. (Mas pode)
Para verificar se os dados de um arquivo estão corretos ao extraí-lo, cada arquivo ou bloco de dados terá um CRC ou código de detecção de erros associado a ele.
Ao descompactar um arquivo faz muito sentido, do ponto de vista da eficiência, fazer a verificação de errosantesgravar dados no disco. Caso contrário, você estará desperdiçando recursos preciosos lendo o arquivo, gravando-o no disco e depois relendo os dados no disco para fazer a verificação de erros. Com um arquivo grande ou em um sistema com memória limitada, isso poderia duplicar o tempo necessário para descompactar um arquivo, o que seria inaceitável. Presumo, neste caso, que a leitura e a gravação do disco sejam a parte mais lenta do processo.
Se você fizer a verificação antes de gravar, poderá transmitir efetivamente o arquivo através do descompressor, através do seu algoritmo de verificação de erros, depois para o disco e assumir que o subsistema do disco sabe o que está fazendo. Tarefa concluída.
Ao fazer desta forma, "testar" o arquivo torna-se uma operação gratuita. Você segue exatamente as mesmas etapas da descompactação, mas simplesmente joga fora os dados sem gravá-los no disco.
Espero fortemente que seja assim que funcione, porque gravar tudo em disco simplesmente para testar um arquivo parece uma loucura e não seria mais rápido do que uma descompactação "real" dos dados. O fato de o "teste" ser mais rápido implica que pelo menos uma etapa, provavelmente a gravação de dados no disco, será ignorada.
Responder2
Não, não importa - pelo menos não na versão 19.00.
Testar vários arquivos em paralelo funciona muito bem em unidades de estado sólido, mas geralmente prejudica o desempenho em unidades mecânicas - é necessária muita busca para ler vários arquivos em paralelo. Assim, a seguinte recomendação pode ser feita:
Ao testar arquivos em unidades de estado sólido (SSD NVMe ou SATA), inicie tantos processos quantos núcleos você tiver (se puder).
Ao testar arquivos na mesma unidade mecânica (ou volume RAID mecânico), inicie um ou no máximo dois processos.
Ao testar arquivos em unidades USB, os resultados podem variar.
A triste maioria dos "pen drives" ou "sticks" USB comuns são terrivelmente lentos, mesmo durante a leitura - ou seja, longe de saturar a largura de banda da interface USB. Algumas dessas unidades ficam ainda mais lentas ao acessar dados de diversas áreas diferentes da unidade simultaneamente. Isso é causado pela RAM limitada no controlador de disco. O controlador não consegue encaixar todos os metadados necessários para acessar toda a unidade na RAM de uma só vez e acabará relendo os metadados da mídia flash à medida que altera as áreas de leitura na unidade, muitas vezes tendo que seguir cadeias de links para encontre. Essas leituras de metadados geralmente não são paralelizadas pela unidade, mesmo que o layout da memória flash permita, e muitas vezes também são implementadas usando caminhos de código dedicados que são apenas lentos.
A única maneira segura de lidar com isso é fazer um teste de largura de banda. Suponha que você precise verificar os arquivos a, b, c, d, ee f, todos aproximadamente na mesma ordem de magnitude em termos de tamanho. Eles precisam ser classificados em ordem decrescente por tamanho. Primeiro, cronometre a verificação ae calcule a largura de banda BW_a = time_a / size_a. Em seguida, faça a verificação de be cem paralelo e calcule essas larguras de banda. Contanto que a soma sum_BW_bcseja maior que BW_a, você estará ganhando desempenho. Em seguida, verifique e d, em paralelo, calcule essas larguras de banda. Contanto que a soma seja maior que , você estará ganhando desempenho. E assim por diante. Eventualmente, você alcançará o número de fluxos em que a largura de banda total cai em comparação com o teste anterior. Eles continuam verificando os arquivos restantes usando o número menor de fluxos anterior.efsum_BW_defsum_BW_bc
Este método pode ser aplicado a qualquer unidade, embora a queda de desempenho com unidades mecânicas seja tão acentuada que pode afetar indevidamente o desempenho geral do seu processo de verificação. Por isso, os testes paralelos devem ser encerrados quando se sabe que sua largura de banda é inferior a 90% da largura de banda da etapa anterior. Você pode fazer isso recalculando a largura de banda a cada segundo em que o teste é executado e encerrando o teste quando a largura de banda estiver abaixo do ponto de corte.