Чому ці копії SD-карт мають різні ша1суми за своїм вмістом?


17

У мене є купа SD-карт SDHC класу 10 UHS-1 від різних виробників. Всі вони розподілені наступним чином

 $ sudo fdisk -l /dev/sdj
Disk /dev/sdj: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0000de21

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdj1          2048  1050623  1048576  512M  c W95 FAT32 (LBA)
/dev/sdj2       1050624  2099199  1048576  512M 83 Linux
/dev/sdj3       2099200  3147775  1048576  512M 83 Linux
/dev/sdj4       3147776 31116287 27968512 13.3G 83 Linux

Я скопіював карти копіювання карт пам'яті . Усі картки мають однаковий вміст.

Коли я монтую другий розділ будь-яких двох карт SD і порівнюю вміст, вони точно однакові.

 $ sudo mount -o ro /dev/sdg2 /mnt/system-a/
 $ sudo mount -o ro /dev/sdj2 /mnt/system-b/
 $ diff -r --no-derefence /mnt/system-a /mnt/system-b/
 $ # prints nothing^

Однак, якщо порівнювати ша1сум розділів, вони іноді відрізняються

 $ sudo dd if=/dev/sdg2 | sha1sum
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.3448 s, 43.5 MB/s
ee7a16a8d7262ccc6a2e6974e8026f78df445e72  -

 $ sudo dd if=/dev/sdj2 | sha1sum
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.6412 s, 42.5 MB/s
4bb6e3e5f3e47dc6cedc6cf8ed327ca2ca7cd7c4  -

Дивніше, якщо я порівнюю ці два накопичувачі за допомогою двійкового інструменту, що відрізняється radiff2, я бачу наступне

 $ sudo dd if=/dev/sdg2 of=sdg2.img
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.2378 s, 43.9 MB/s

 $ sudo dd if=/dev/sdj2 of=sdj2.img
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB) copied, 12.2315 s, 43.9 MB/s

 $ radiff2 -c sdg2.img sdj2.img
767368

767368 змін, хоча diffне бачив різниць у вмісті!

А для розумності, якщо я порівняю дві секції, що мали однакову ша1суму, я бачу наступне

 $ radiff2 -c sdj2.img sdf2.img
0

0 змін!

Ось розбивка різних ша1сумів, які я бачу з різних карт. Схоже, виробник карти сильно впливає на те, що ша1сум я отримую, коли використовую дд, щоб прочитати накопичувач.

введіть тут опис зображення

Незважаючи на відмінності в sha1sums, всі ці картки працюють для моїх цілей. Однак це ускладнює перевірку інтегральності, оскільки я не можу порівнювати ша1суми.

Як можливо, два розділи SD-карти можуть мати різні ша1суми, але при встановленні мають абсолютно однаковий вміст?


Відповідь: Отже, зараз це працює, як очікувалося. Щоб вияснити, непослідовність викликала копіювач SySTOR, який я використовував. У налаштуваннях копіювання у мене було скопійовано інформацію про розділи та файли, але не потрібно було бітів, щоб переконатися, що існує одна відповідність.


3
Яке тестування ви робите з такою купою карт? :)
hjk

Якщо ви порівнюєте їх після монтажу, у цьому є ваша проблема.
Девід Хольцер

Відповіді:


18

Чи порівняли ви їх вміст одразу після написання дублюючого вмісту? Якщо так, вони повинні вийти точно так само. Наприклад,

# Duplicate
dd bs=16M if=/dev/sdg of=/dev/sdk

# Comparing should produce no output
cmp /dev/sdg /dev/sdk
# Compare, listing each byte difference; also no output
cmp -l /dev/sdg /dev/sdk

Це справедливо лише в тому випадку, якщо картки мають однаковий розмір. Іноді навіть різні партії карток одного і того ж виробника та моделі виходять з дещо різними розмірами. Використовуйте blockdev --getsize64для отримання точного розміру пристрою.

Крім того, якщо обидві картки мають абсолютно однакові розміри, але ви написали зображення на обох картах, яке було меншим, ніж ємність карт, то сміття, яке з’являється після закінчення зображення, може спричинити повідомлення про різниці.

Як тільки ви змонтуєте будь-яку файлову систему на пристрої, ви почнете бачити відмінності. Реалізація файлової системи запише різні файли у файлову систему, такі як порожній журнал або прапор / часова мітка, щоб позначити файлову систему чистою, і тоді ви більше не побачите однакового вмісту. Я вважаю, що це може бути за певних обставин, навіть якщо ви монтуєте файлову систему лише для читання.


Чи потрібно використовувати ОП blockdev --getsize64? Схоже dd, оголошує кількість даних, яку вони читають.
G-Man каже: "Відновіть Моніку"

3
EIBTI Запит на розмір робить його дійсно зрозумілим. ddповідомить, скільки скопійовано . У разі невідповідності розміру між файлом зображення, розміром одного пристрою та розміром іншого пристрою тощо ..., який може бути розміром джерела, точкою визначення або обома.
Целада

Ти маєш рацію. Вони повинні бути, і вони точно такі самі. Подивившись далі на це, я виявив, що невідповідність була викликана настройкою копіювання на моєму дублікаторі SySTOR. Коли я знімаю ddSD-картки з комп'ютера (як це робилося з головним зображенням для копіювача), всі шасуми відповідають. Я змінив налаштування на SySTOR з "лише системних даних і файлів" на "цілі носії", і тепер усі дублюються картки мають відповідні шасуми
peskal

8

На основі відповіді Селади: З одного боку, ви робите diff(рекурсивний) між двома встановленими файловими системами. З іншого боку, ви робите двійкове порівняння між пристроями, на яких є файлові системи - мабуть, після встановлення файлових систем. Це яблука та гранати.

Операція на рівні змонтованої файлової системи може бачити лише вміст даних файлів у файлових системах. Бінарне порівняння між пристроями розглядає дані та метадані . Я трохи здивований 767368 відмінностями, але я можу здогадатися на декілька:

  • Коли ви монтуєте файлову систему, ядро ​​записує поточний час у суперблок файлової системи як "час монтування". Якщо встановлено обидва пристрої (а не в точному то же час), то «встановити час» в суперблоці буде відрізнятися.
  • Якщо ви виконуєте двійкове порівняння на рівні пристрою після рекурсивної файлової системи diff, кожен файл на кожному пристрої оновлював би час доступу (у inode).

PS Чи потрібно вам ddтак багато користуватися? Що станеться, якщо ви зробите radiff2 -c /dev/sdg2 /dev/sdj2 або sha1sum /dev/sdg2?


Чи застосовується це навіть при монтажі накопичувача як лише для читання? Я зробив порівняння шасума перед монтажем, і вони все ще відрізняються. Я також ніколи не бачив зміни шасума після монтажу як лише для читання. - Також ви маєте рацію, я повинен виграти марну нагороду DD: p
peskal

(1) Ні, як ви підозрюєте (тобто, відповідно до вашого досвіду), монтаж файлової системи як ro(лише для читання) не повинен спричиняти (або допускати) будь-яких змін. (Хоча я бачив один-два випадки, коли програмне забезпечення робило щось інше, ніж те, що воно повинно робити.) (2) Прочитавши ваші коментарі (по одній на кожну відповідь, під час написання цього запису), я все ще не зовсім розумію, що сталося. Будь ласка, відредагуйте своє запитання чи опублікуйте відповідь, що пояснює обставини, за яких ви отримали збій порівняння (тобто виявили відмінності) одразу після дублювання (до монтажу),… (Продовжував)
G-Man каже: «

(Продовжував)… і що ви зробили, щоб вирішити це? (3) Мені це подобається, але чи варто його називати "UUOD", "UUODD" або "UUDD"? Я голосую за "УУД", але, мабуть, ми повинні взяти це за Meta. :-) ⁠
G-Man каже: "Відновіть Моніку"
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.