Por que posso ter certeza de que o GNU Parted não corrompeu nem um único bit depois de encolher minha partição?

Question

Reduzi minha partição raiz e parece legal. Mas estou pensando em sobrescrever agora pelo menos os arquivos mais importantes da cópia de backup (unidade externa, rsync, backup semanal) para ter certeza de que nenhum dos meus arquivos foi corrompido durante o encolhimento. Isso é provavelmente uma perda de tempo (e talvez isso possa resultar em mais fragmentação).

Eu posso verificar se os arquivos estão OK depois de movê-los durante o encolhimento por meio de uma comparação de CRC com aqueles no backup (por exemplo, com md5sum), como diz unser gentilmente em sua resposta.

Mas, especificamente, gostaria de uma breve explicação sobre o algoritmo que o GNU Parted usa para garantir que não ocorra corrupção de dados ao mover informações de um setor do disco para outro, antes da redução da partição. Existe tal algoritmo, ou o programa copia bytes cegamente? Eu gostaria de ler uma explicação simples.

    

Answer 1

Why can I rest assured that GNU Parted has not corrupted a single bit after shrinking my partition?

Você não pode, na verdade, gparted man página diz claramente (sob NOTES ):

Editing partitions has the potential to cause LOSS of DATA.
......
You are advised to BACKUP your DATA before using the gparted application.

Reinicialize seu sistema após redimensionar a partição e execute fsck . Se não encontrar nenhum erro, a operação foi bem-sucedida e os dados estão intactos.
Houve problemas no passado com gparted corrompendo dados ao redimensionar partições, mesmo que não estivesse reportando nenhum erro (por exemplo, ver este tópico em seu fórum e o aviso vinculado lá).

Ao redimensionar, (g)parted only moves the END position of partition NUMBER. It does not modify any filesystem present in the partition . Abaixo, gparted usa ferramentas específicas de fs para aumentar / diminuir o sistema de arquivos.
Você pode obter informações detalhadas para cada operação, de acordo com o manual :

• To view more information, click Details. The application displays more details about operations.

• To view more information about the steps in each operation, click the arrow button beside each step.

Vamos ver o que realmente acontece ao reduzir uma partição ext4 (ignorando as etapas calibrate & fsck ):

shrink file system  00:00:02    ( SUCCESS )

resize2fs -p /dev/sdd1 409600K

Resizing the filesystem on /dev/sdd1 to 409600 (1k) blocks.
Begin pass 3 (max = 63)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sdd1 is now 409600 (1k) blocks long.

resize2fs 1.42.12 (29-Aug-2014)

Como você pode ver, gparted não faz nada, apenas chama resize2fs -p com o dispositivo especificado e novo tamanho como argumentos. Se você tiver interesse no algoritmo, consulte resize2fs.c . Resumindo:

Resizing a filesystem consists of the following phases:

1.  Adjust superblock and write out new parts of the inode table
2.  Determine blocks which need to be relocated, and copy the
    contents of blocks from their old locations to the new ones.
3.  Scan the inode table, doing the following:
       a.  If blocks have been moved, update the block
              pointers in the inodes and indirect blocks to
              point at the new block locations.
       b.  If parts of the inode table need to be evacuated,
              copy inodes from their old locations to their
              new ones.
       c.  If (b) needs to be done, note which blocks contain
              directory information, since we will need to
              update the directory information.
4.  Update the directory blocks with the new inode locations.
5.  Move the inode tables, if necessary.

O redimensionamento do sistema de arquivos deve ser uma operação segura, de acordo com um dos autores Ted Tso:

resize2fs is designed not to corrupt data even if someone hits the Big Red switch while it is operating. That was an explicit design goal.

mas como todo código, não é livre de erros.
Quando fs resize for concluído, gparted reduzirá a partição:

shrink partition from 500.00 MiB to 400.00 MiB  00:00:00    ( SUCCESS )

old start: 2048
old end: 1026047
old size: 1024000 (500.00 MiB)
new start: 2048
new end: 821247

new size: 819200 (400.00 MiB)

Linha de fundo: sempre faça backup de seus dados antes de alterar partições / sistemas de arquivos e execute fsck após fazer as alterações.

    

Answer 2

Existem vários utilitários que funcionam de uma maneira semelhante que você pode usar para isso: md5sum , sha1sum ... sha512sum :

Na sua partição atual:

find . -type f -print0 | xargs -0 md5sum > /var/tmp/checksum.lst

e, em seguida, no diretório do seu backup:

< /var/tmp/checksum.lst md5sum -c 

Você pode substituir md5sum por qualquer outro comando. Embora md5sum e sha1sum não sejam mais seguros (por exemplo, um arquivo diferente pode ser forjado dando o mesmo hash), o tempo de computação extra para hashes mais longos não lhe dá muito mais confiança sobre os arquivos serem idênticos ou não.