Клонирование жесткого диска и несовпадение контрольных сумм
Я думаю, что это - желаемое поведение от top: это выходит только на команде "q" с клавиатуры.
Код top вероятно, установки сигнализируют о функциях ловца, любом с a signal() системный вызов или a sigaction() системный вызов. Мое предположение было бы этим когда top периодически обновляет экран, он получил сигнал, возможный от alarm() системный вызов или что-то как этот.
Вы уверены это cat не выходит на Ctrl-C или управлении-\? Обе из тех ключевых хорд обычно генерируют SIGINT и SIGQUIT соответственно. cat казалось бы, не извлек бы выгоду из восстановления ни с одного из тех двух сигналов.
Одним способом проверить, что думает Ваш tty драйвер, являются ключевые хорды для SIGINT и SIGQUIT:
stty -a
На моей машине это говорит что-то как:
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
"Предают земле =, ^C" и "выходят =, ^\\" средний "Отправляют SIGINT в текущий приоритетный процесс на Ctrl-C", и "Отправляют SIGQUIT в текущий приоритетный процесс на обратной косой черте Управления". Те два становились измененными так или иначе?
Вам можно было бы установить Вашу оболочку для захвата сигналов. В zsh и ударе, команде:
trap "" INT
сохраняет Ctrl-C (в том же xterm) от уничтожения последующего вызова cat. Но то "прерывание" не сохраняет a kill -QUIT от порождения cat обработайте для выхода. Тем не менее, необходимо проверить удар или zsh или файлы точки ksh для trap "" INT вызовы.
Вы не упоминаете, какая версия ядра, какой дистрибутив и что окружает, Вы используете. Упоминание о тех вещах могло бы получить Вас лучший ответ.
Два входа имеют одинаковую криптографическую контрольную сумму, только если они идентичны. Идентичные входы по определению должны иметь одинаковую длину. Иметь приблизительно одинаковую длину недостаточно, они должны иметь точно такую же длину.
Жесткий диск емкостью 1 ТБ на практике имеет объем, очень близкий к 10004 = 1 000 000 000 000 000 байт. SSD емкостью "1 ТБ" обычно ближе к 2 = 10244 = 1 099 511 627 776 байт. Итак, ваш SSD немного больше, чем HDD, поэтому при копировании была перезаписана большая часть SSD, но в конце осталось немного неиспользуемого пространства. Когда вы рассчитывали контрольную сумму SSD, вы включили в нее все содержимое, включая неиспользуемое пространство.
Вы можете вычислить контрольную сумму данных на SSD, проверив размер жесткого диска, который fdisk /dev/sdh сообщит вам (предполагается, что /dev/sdh - это HDD). Также есть размер в /proc/partitions, но он в кБ, без указания, что размер не кратен 1 кБ - я думаю, что все жесткие диски такого размера имеют размер, кратный 4 кБ, так что это должно быть нормально. Затем вы можете выполнить (предполагая, что /dev/sdd - это SSD, а 1000196757504 - размер HDD) для вычисления контрольной суммы копии.
Но вычисление этих контрольных сумм не очень полезно. Если бы во время копирования произошла ошибка, cat сказал бы вам об этом. Сравнение дисков может быть полезно в качестве проверки правильности копирования, но монтирование разделов служит той же цели.
Обратите внимание, что после монтирования разделов их содержимое будет отличаться, поскольку монтирование записывает некоторые метаданные в файловую систему, например, дату последнего монтирования. Даже монтирование только для чтения может фактически изменить устройство, в частности, для воспроизведения журнала на журнальных файловых системах.
Проблема с запуском хэша образа диска заключается в том, что это однобитовая мера; он только говорит вам, является ли копия побайтной идеальной. И особенно с образами дисков, в которых есть файловые системы, у них очень мало причин быть побайтными. Даже после прямого зеркалирования любая одиночная ошибка - даже несущественная - приведет к ее поломке, как и любые изменения на дисках, включая те, которые происходят в результате любых манипуляций с разделами, или монтирования файловых систем, или ... чего угодно.
Более полезным было бы смонтировать задействованные файловые системы, а затем выполнить что-то вроде cd / mnt / mountpoint; найти . -type f -exec sha256sum {} \ +> ~ / контрольные суммы . Затем вы можете смонтировать второй диск и запустить sha256sum -c ~ / checkums . Это сообщит вам, какие файлы были изменены. (Вполне возможно, что никакие файлы не были изменены, а изменение на диске связано с метаданными FS, границами разделов или чем-то еще не очень значительным.)