O tamanho do arquivo de 60.0 PB está incorreto. Pode excluí-lo causar perda de dados?

Question

Durante o backup de alguns dados (um diretório pessoal de 200 GB) com rsync , recebi um erro de E / S para um arquivo específico, após o qual rsync continuou "normalmente" com seu backup . O arquivo de origem do problema mostrou ter um tamanho de arquivo de 72 bytes.

Eu cancelei rsync e executei o mesmo comando novamente. Desta vez, o mesmo arquivo mostrou estar transferindo dados .. muitos dados ... e mais dados, e mais ... Eu verifiquei o tamanho do arquivo de destino, e ele era de até 13 GB! então usei Ctrl-c para cancelar rsync .

Ao verificar novamente o tamanho do arquivo de origem, no Nautilus, ele mostrou um tamanho de 60.0 PB (Peta Bytes!) em uma unidade de 500 GB.

Agora, o ponto principal de tudo isso: Poderia / poderia excluir esse arquivo causar perda de dados em outros arquivos, vendo que o sistema de arquivos pode perceber que ele é muito maior do que realmente é ... O sistema de arquivos é ext4 ..

Eu poderia passar por cima dele com uma exceção rsync , mas estou particularmente interessado no que poderia acontecer se fosse excluído.

UPDATE: o destino e a origem são ext4

Quanto às sugestões de ser um arquivo esparso: se é um arquivo esparso, por que ele mostraria tamanhos diferentes de um minuto para o outro? O arquivo foi certamente (?) Não em uso no momento. É um arquivo ~/.macromedia/Flash_Player/#SharedObjects/someting-or-other.sol , do qual há muitos mais arquivos .sol nesse diretório .. além disso ele mostrou um erro de E / S na primeira passagem .

Além disso, de acordo com man rsync , a opção -S sugerida é lidar com arquivos esparsos eficientemente , não corretamente , o que sugere que, embora eu não estava usando -S ele deve copiar um arquivo esparso com precisão em ambos os casos: o que não aconteceu, e mesmo se for um arquivo esparso, sendo 60.0 Peta Bytes parece certamente (?) ser um erro no arquivo sistema, em algum lugar ... e essa é minha preocupação principal: Se houver um glytch no sistema de arquivos, a exclusão desse arquivo pode ter repercussões em outros arquivos?

Mais especificamente: como escreveu 13 GB de dados e subindo! quando eu cancelei, poderia também apagar 13 GB - 60 PB de dados quando eu apagá-lo?

    

Answer 1

Parece que o sistema de arquivos de origem está danificado, normalmente devido a um bug do kernel ou a RAM ruim (é mais provável que um disco danificado resulte em arquivos ilegíveis do que em dados corrompidos). Neste ponto, todas as apostas estão desativadas. No entanto, se a corrupção foi muito localizada, é apenas aquele inode de um arquivo que está corrompido e outros arquivos não estão danificados, portanto, você pode excluir com segurança o arquivo. Observe que não há como testar essa suposição.

Minha recomendação é:

1. Faça um teste de RAM ou conecte o disco em outra máquina.
2. Verifique se você fez backup de todos os seus dados.
3. Verifique a integridade do disco com o SMART, se possível.
4. Executar fsck .
5. Se o disco ainda estiver bom, continue usando-o.

Answer 2

É um arquivo esparso . Você deve considerar o uso de -S , para que o arquivo seja tratado da maneira mais adequada possível.

    

Answer 3

Este é provavelmente um arquivo esparso . (se não for, comece a correr agora !) Não realmente ocupa todo esse espaço, ele tem buracos. Talvez um buraco grande.

Exclua-o do lado rsync target e adicione a opção -S (sparse) a rsync para ter certeza de que reconhece e lida com arquivos esparsos.

O tipo de sistema de arquivos de destino deve suportar arquivos esparsos também. (versão curta: ext[234] do, NTFS não, FAT não)