(cp é para cat AS mv é para?) mv vários arquivos em um arquivo em vez de cat * rm *

Question

Para tudo nessa questão, finja que o sistema tem apenas um disco e um sistema de arquivos. (não estamos escrevendo para diferentes partições, discos ou sistemas de arquivos)

Eu estou trabalhando em um projeto que cat s arquivos muito grandes de .MTS em um enorme arquivo .MTS. Isso requer a leitura de cada arquivo pequeno e gravá-los em um novo arquivo maior, em seguida, excluindo os arquivos pequenos. Isso leva muito tempo com arquivos tão grandes.

Meu entendimento - cp demora mais do que mv porque cp lê o arquivo e o grava em um local diferente no disco. Por outro lado, mv não copia nem move o arquivo. mv remove a referência ao arquivo e cria um novo no novo local. Por exemplo, mv /tmp/foo /tmp/bar deixa o arquivo como está no disco e remove a referência que direciona /tmp/foo para o arquivo no disco e adiciona a nova referência que aponta /tmp/bar para o arquivo no disco.

A pergunta:

cat é como cp porque copia o arquivo para o novo local. Com arquivos tão grandes e sem necessidade de arquivos menores quando terminar, há algo semelhante a cat que usa mv em vez de cp ?

Teoria (posso estar errado)

Já é comum que os arquivos sejam armazenados espalhados pela unidade. Por exemplo, um arquivo de 2 GB pode ter vários fragmentos menores armazenados em diferentes partes da unidade. Desta forma, quando um arquivo de 5K é excluído, ele pode ser substituído por uma parte de um arquivo de 20MB. Se deixarmos os arquivos de 2GB onde eles estão e apenas referenciarmos todas as partes, parece que poderíamos ter o mesmo efeito que cat foo/* >> bar/bigfile.MTS; rm foo/* em uma fração do tempo.

Se não há nada lá fora que faz isso e é uma má idéia, alguém pode me dar exemplo do porquê? É ruim encorajar o disco com pedaços de arquivos espalhados?

    

Answer 1

O maior obstáculo para uma ferramenta como essa existente é que a menos que o tamanho de cada arquivo (exceto o último) sendo concatenado seja exatamente divisível pelo tamanho do bloco (estou um pouco incerto sobre a terminologia correta aqui), você acabar com "lacunas" com dados de lixo entre seus arquivos concatenados no arquivo final.

Isso ocorre porque os dados do arquivo são normalmente armazenados em blocos com tamanhos específicos no sistema de arquivos, de modo que um arquivo de 618 bytes armazenado em um sistema de arquivos usando blocos de 32 bytes ocuparia 618/32 = 19.3125 blocos, ou seja, 19 blocos completos e cerca de 1/3 de um bloco adicional.

Supondo que você queria combinar dois arquivos como este sem considerar o meu obstáculo, você simplesmente apontaria o "novo arquivo" para os blocos do primeiro arquivo, mais os blocos do segundo arquivo, certo?

Com essa abordagem ingênua, você acabaria com um arquivo de 40 blocos, com o bloco 20 sendo 1/3 sensível e 2/3 de lixo, e o bloco 21 iniciando os dados do segundo arquivo.

Com alguns formatos de arquivo, você pode fazer alguns cálculos e manipulações de cabeçalhos de arquivos para dizer basicamente ao aplicativo que usará o arquivo para pular as partes de lixo, mas isso é mais uma solução de band-aid do que uma adequado.

    

Answer 2

Veja uma pergunta semelhante no link do stackoverflow

A resposta simples é esta -

It could only work if all the files (except the last) were guaranteed to have a size that is a multiple of the filesystem's block size.

Porque o sistema de arquivos precisa ler todos os blocos até o final do arquivo.