Почему я могу быть уверен, что GNU Parted не испортил ни одного бита после сокращения моего раздела?

Я сжал свой корневой раздел, и он кажется приятным. Но я думаю о том, чтобы переписать сейчас по крайней мере самые важные файлы из резервной копии (внешний диск, rsync, еженедельное резервное копирование), чтобы быть уверенным, что ни один из моих файлов не был поврежден во время сокращения. Вероятно, это пустая трата времени (и, возможно, это может привести к большей фрагментации).

Я могу проверить, что файлы в порядке после их перемещения во время сокращения с помощью сравнения CRC с данными в резервном копировании (например, с md5sum), поскольку один из них нечетко говорит в своем ответе.

Но я хотел бы кратко рассказать об алгоритме, который использует GNU Parted для того, чтобы предотвратить повреждение данных при перемещении информации из одного сектора диска в другой до сжатия раздела. Есть ли такой алгоритм, или программа копирует байты вслепую? Я хотел бы прочитать простое объяснение.

2 Solutions collect form web for “Почему я могу быть уверен, что GNU Parted не испортил ни одного бита после сокращения моего раздела?”

Почему я могу быть уверен, что GNU Parted не испортил ни одного бита после сокращения моего раздела?

На самом деле вы не можете сказать, что gparted man page четко (по NOTES ):

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

Перезагрузите систему после изменения размера раздела и запустите fsck . Если он не обнаружил ошибок, операция была успешной и данные остались нетронутыми.
В прошлом были проблемы с gparted corrupting data при изменении размера разделов, хотя он не сообщал о какой-либо ошибке (например, см. Эту тему на своем форуме и предупреждение, связанное с ней).


При изменении размера (g)parted moves the END position of partition NUMBER. It does not modify any filesystem present in the partition только moves the END position of partition NUMBER. It does not modify any filesystem present in the partition moves the END position of partition NUMBER. It does not modify any filesystem present in the partition . Внизу gparted использует специальные инструменты fs для увеличения / сжатия файловой системы.
Вы можете получить подробную информацию для каждой операции в соответствии с онлайн- руководством :

  • 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.

Посмотрим, что он на самом деле делает при сжатии раздела ext4 (пропуская шаги 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) 

Как вы можете видеть, gparted ничего не делает, он просто вызывает resize2fs -p с указанным устройством и новым размером в качестве аргументов. Если вас интересует алгоритм, вы можете посмотреть на resize2fs.c . Вкратце:

 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. 

Изменение размера файловой системы должно быть безопасной операцией, по словам одного из авторов , Ted Tso:

resize2fs разработан, чтобы не испортить данные, даже если кто-то попадает в переключатель Big Red во время работы. Это была явная цель дизайна.

но, как и весь код, он не является ошибкой.
После изменения размера fs gparted сжимает раздел:

 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) 

Итог: всегда создавайте резервные копии своих данных перед изменением разделов / файловых систем и запускать fsck после внесения изменений.

Есть несколько утилит, которые функционируют аналогичным образом, что вы можете использовать для этого: md5sum , sha1sumsha512sum :

В текущем разделе:

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

а затем в каталоге вашей резервной копии:

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

Вы можете заменить md5sum на любую из других команд. Хотя md5sum и sha1sum более не защищены (например, другой файл может быть подделан с одинаковым хешем), дополнительное время для более длинных хэшей не дает вам большей уверенности в том, что файлы идентичны или нет.

  • gparted (live usb) говорит, что мой раздел установлен, но где?
  • Невозможно переформатировать карту Micro SD
  • Недопустимая таблица разделов!
  • Я не могу понять, как расширить мой домашний раздел Arch на свободное место
  • Как изменить размер разделов на полный образ жесткого диска?
  • Проблема Garted Linux Mint 18.1
  • Разверните раздел в Gparted назад или перемещение назад + expand
  • Безопасно ли использовать GParted при загрузке?
  • Linux на Dell Inspiron 630m
  • Как увеличить размер файловой системы для соответствия раздела
  • Переместите свободное пространство с конца диска на первый раздел с gparted
  • Linux и Unix - лучшая ОС в мире.