11/16/2006

Как проверить CD и DVD диск после записи

Задача: диск записан - нужно проверить правильность записанных данных.
Решение: для этого есть простые средства, типа dd и md5sum. Реализация в виде скриптов.
Для этого нам нужен md5sum и несколько утилит, входящих в любой уважающий себя дистрибутив. Есть несколько способов, приведу известные мне ниже (если кто предложит ещё - с удовольствием добавлю).

Подсчёт контрольной суммы файла
Для того, чтобы просто подсчитать MD5-сумму уже имеющегося iso-образа, пишем в консольке
md5sum my.iso
Через некоторое время вы увидите что-то вроде этого:

e941bb0ecac20a2043c9f8e69fbab63a my.iso
А можно и так:
cat my.iso | md5sum
Увидите то же самое:
e941bb0ecac20a2043c9f8e69fbab63a
Для скачиваемых из Интернета iso-образов обязательно рядом с ним лежит либо файл MD5SUMS, или такой же по имени файл, только с расширением md5 - не забывайте их скачивать. Так можно будет всегда проверить, правильно ли вы скачали образ диска.
Кстати говоря, кроме метода MD5 встречается SHA1 - его особенно любят федоровцы. Синтаксис тот же, что и у md5sum, только утилита называется соответственно sha1sum.


Проверка правильности записи на CD и DVD диск
Есть несколько способов сделать это, и большинство из них основано на подсчёте контрольной md5-суммы исходного образа и записанного на диск. Их совпадение гарантирует правильность записи и то, что файлы на диске не повреждены.

Способ #1: утилита dd

Эта утилита входит в состав любого дистрибутива и является чрезвычайно полезной во многих случаях - здесь мы тоже будем её использовать. Однако в случае с CD и DVD дисками есть свои тонкие моменты, которые необходимо учитывать, иначе вы получите неправильные результаты.

Для CD-дисков

Вставляем пропаленный диск, и, не монтируя его, пишем в консольке:

dd if=/dev/cdrom | md5sum

Если у вас другое устройство для чтения/записи дисков (не /dev/cdrom) - измените команду соответственно. После выполнения этой команды вы увидите:

$ dd if=/dev/cdrom bs=2048 | md5sum 355562+0 входных записей
355562+0 выходных записей
728190976 bytes transferred in 299,413377 seconds (2432059 bytes/sec)
e941bb0ecac20a2043c9f8e69fbab63a -


Если у вас есть файл MD5SUMS или my.iso.md5 - проверьте, совпадают ли контрольные суммы. Если у вас такого файла нет, но есть образ диска - просто подсчитайте его контрольную сумму, как говорилось выше: md5sum my.iso

Для DVD-дисков
Здесь всё немного сложнее: дело в том, что при записи на DVD пишется так же и служебная информация, поэтому для проверки DVD-дисков утилитой dd нужно точно указывать размер и количество блоков. Для того, чтобы узнать, сколько значимых блоков (extents) имеется в iso-образе, выполняем команду (вводите именно так, как написано, меняя тольк имя образа):

echo $(( $(ls -l my.iso | awk '{ print $5 }') / 2048 ))
Результатом будет число блоков - это число нам потребуется для команды dd:
169383

Теперь, зная, что размер блока равен 2048 байт и количество блоков на DVD-диске, даём команду:
dd if=/dev/cdrom bs=2048 count=169383 | md5sum


Результатом её выполнения будет вывод:
$ dd if=/dev/cdrom bs=2048 count=169383 | md5sum 169383+0 records in
169383+0 records out e941bb0ecac20a2043c9f8e69fbab63a -

Как видно, что записанный на DVD образ и isoшник на жёстком диске совпадают, так что запись прошла успешно.

Подчёркиваю:

для DVD-дисков обязательно нужно указать размер и количество считываемых блоков, иначе утилита dd может считать служебные данные, что исказит значение контрольной суммы и вы будете думать, что запороли болванку в то время как (возможно) данные записаны верно. Более подробно об этом методе говорится, например, здесь.

Пример неправильного подсчёта контрольной суммы: Взяли iso-образ, пропалили его:
growisofs -Z /dev/cdrom=my.iso
Утилита напишет:
builtin_dd: 169392*2KB out @ average 4.4x1385KBps
А теперь считаем данные
dd if=/dev/cdrom | md5sum
169392+0 records in
169392+0 records out
1188f67d48c9f11afb8572977ef74c5e -

Сверяем:
md5sum my.iso:
e941bb0ecac20a2043c9f8e69fbab63a my.iso

Не сходится! А всё почему? Потому, что
утилита dd считали все блоки (169392), как вы её и просили. Но это неправильно: значащих блоков там меньше (169383), поэтому контрольная сумма совсем другая. Всегда указывайте количество и размер блоков при проверке DVD-дисков!


Способ #2: утилита diff
Другой способ, не требующий наличия программы md5sum, был предложен здесь же, в комментариях. Заключается он в остроумном использовании команды diff, которая выдаёт информацию обо всех файлах, в которых совпадает содержимое. Для этого нужно смонтировать только что записанный диск:
mount -t iso9660 /dev/cdrom /mnt/cdrom
и (в другую точку монтирования, на петлевое устройство) имеющийся iso-образ.
sudo mount -t iso9660 my.iso /mnt/flash/ -o loop
Затем напишите
diff -urN /mnt/cdrom /mnt/flash
Если утилита ничего не напишет - значит, все файлы совпадают и запись диска проведена правильно. Это работает и для CD, и для DVD-дисков.


Способ #3: утилита readcd (только для CD-дисков) Эта утилита входит в комплект cdrtools и производит посекторное чтение данных с диска. Очень удобно как для проверки, так и для сдирания образа с какого-нибудь принесённого диска. По этому поводу мной написан простенький скрипт на баше:

#! /bin/sh
if [ -z $1 ]; then
echo "Скорость считывания?"
read kmvISOspeed;
else
kmvISOspeed=$1;
fi
readcd dev=ATAPI:0,0,0 speed=$kmvISOspeed f=temp.raw;
md5sum temp.raw
Некоторые пояснения к скрипту. Для того, чтобы выяснить адрес для ATAPI, запускаем
sudo cdrecord -scanbus dev=ATAPI
Выдаст он нам что-то вроде:

Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Joerg Schilling NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord and thus may have bugs that are not present in the original version. Please send bug reports and support requests to . The original author should not be bothered with problems of this version. cdrecord: Warning: Running on Linux-2.6.15.7 cdrecord: There are unsettled issues with Linux-2.5 and newer. cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris. scsidev: 'ATAPI' devname: 'ATAPI' scsibus: -2 target: -2 lun: -2 Warning: Using ATA Packet interface. Warning: The related Linux kernel interface code seems to be unmaintained. Warning: There is absolutely NO DMA, operations thus are slow. Using libscg version 'ubuntu-0.8ubuntu1'. cdrecord: Warning: using inofficial version of libscg (ubuntu-0.8ubuntu1 '@(#)scsitransp.c 1.91 04/06/17 Copyright 1988,1995,2000-2004 J. Schilling').
scsibus0:

0,0,0 0) '_NEC ' 'DVD_RW ND-3550A ' '1.05' Removable CD-ROM

0,1,0 1) *

0,2,0 2) *

0,3,0 3) *

0,4,0 4) *

0,5,0 5) *

0,6,0 6) *

0,7,0 7) *
Выделенные полужирным цифры и подставляем в качестве цели для записи - это наш привод.

Резюме
Приведённые способы (в порядке их предпочтительности) позволяют проверить, правильно ли прошла запись на болванку. Этой информации должно хватить для выполнения данной задачи. Но если кто может предложить другие способы - комментарии всегда открыты.

33 комментария:

  1. Единственная проблема, что md5 уже считается ненадёжной. У себя на FreeBSD я использую sha256, хотя конечно, никогда не натыкался на случаи совпадения MD5 у разных файлов.

    ОтветитьУдалить
  2. 2 jankkhvej
    Единственная проблема, что md5 уже считается ненадёжной.
    Для шифрования банковских транзакций в электронных платежах - да. Но ведь тут скачивание файлов. Смысл? :-)

    ОтветитьУдалить
  3. А если просто попробовать переписать данные с диска на комп? так нельзя разве проверить?

    ОтветитьУдалить
  4. 2 kri
    А если просто попробовать переписать данные с диска на комп?
    Ну да, можно. А как "переписать с диска на комп" загрузочный LiveCD? И чем проверить правильность записи его? Вот тут-то нам эти способы и помогают. И потом проще и быстрее: в скрипт завернул и забыл.

    ОтветитьУдалить
  5. Насчёт смысла md5 и sha256

    Честно говоря, не знаю, что там сечас используют для шифрования банковских транзакций, но то, что дистфайлы во фре имеют две контрольные суммы, MD5 и SHA256 - факт.
    И потом я тут тесты сделал простые:

    CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.72-MHz 686-class CPU)
    Origin = "GenuineIntel" Id = 0xf49 Stepping = 9
    Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C
    MOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
    Features2=0x641d<SSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,<b14>>
    AMD Features=0x20100000<NX,LM>
    AMD Features2=0x1<LAHF>
    Logical CPUs per core: 2
    real memory = 1073676288 (1023 MB)
    avail memory = 1037393920 (989 MB)

    solik@solik$ md5 -t
    MD5 time trial. Digesting 100000 10000-byte blocks ... done
    Digest = 766a2bb5d24bddae466c572bcabca3ee
    Time = 4.021527 seconds
    Speed = 248661776.079997 bytes/second
    solik@solik$ sha256 -t
    SHA256 time trial. Digesting 100000 10000-byte blocks ... done
    Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca
    Time = 15.460602 seconds
    Speed = 64680535.240904 bytes/second

    4 и 16 секунд - разница огого, особенно если считать суммы образов iso. Но если подсчёт идёт непосредственно с DVD/CD - смысл одинаков, скорость всё равно ограничена железом.

    ОтветитьУдалить
  6. 2 jankkhvej
    Насчёт смысла md5 и sha256
    Ого! Спасибо огромное - прямо целое исследование! Обязательно включу в пост при следующей правке! Как говорится, приходите ещё :-)

    ОтветитьУдалить
  7. большое спасибо за статью - очень помогла! =)

    ОтветитьУдалить
  8. Если диск не загрузочный и нужно просто прогнать файлы, получить их контрольные суммы или просто проверить читаемость и нет желания копировать все на веник - можно воспользоваться find. Что-то типа:
    find /cdrom/ -exec md5sum {};
    Вместо md5sum можно поставить любую программу. Можно поиграться с фильтрами, чтобы проверять читаемость отдельных файлов.

    ОтветитьУдалить
  9. для cdrom и dvd можно так же использовать cat:
    например cat /dev/cdrw | md5sum

    ОтветитьУдалить
  10. или даже так
    md5sum /dev/cdrom

    ОтветитьУдалить
  11. Как оказалось метод "в лоб" проверки md5 для CD или DVD работает не всегда правильно (и не на всех приводах). Правильное и проверенное решение здесь http://www.troubleshooters.com/linux/coasterless.htm#rawread

    ОтветитьУдалить
  12. Ну да, эти и перечисленные в статьях методы - вариации на тему. Главное, чтобы люди не падали в обморок, если у них не сойдутся md5-суммы для DVD. Кстати, сам по началу так и делал :-)

    ОтветитьУдалить
  13. Еще можнго использовать qpxtool (http://qpxtool.sourceforge.net), которая вам выведет график скорости чтения поверхности диска, а так же проведет еще ряд тестов. Очень полезно тем, что иногда в скорости чтения бывают заметные пробелы, и по ним можно судить о надежности компакт диска.

    А еще, я где-то читал, что CD и DVD надо проверять через несколько дней после записи, да и потом регулярно, раз в несколько месяцев, так как иногда они имеют свойство портиться. Это конечно стоит делать для важных данных, но лучше тогда их вообще дублировать.

    ОтветитьУдалить
  14. 2 Alexander Artemenko
    Еще можнго использовать qpxtool (http://qpxtool.sourceforge.net), которая вам выведет график скорости чтения поверхности диска, а так же проведет еще ряд тестов.
    Спасибо, очень интересная программа, но она проводит тесты дисков - а тут нужна проверка идентичности того, что записывалось, и того, что записалось.

    А еще, я где-то читал, что CD и DVD надо проверять через несколько дней после записи
    Обычно это свойственно низкосортным болванкам и CD/DVD-RW. На них лучше важную информацию не хранить вообще. Всё важное, безусловно, записывается на 2-3 болванки.

    ОтветитьУдалить
  15. Проверял скаченные образы Дэбейна и один из них на md5sum debian-40r1-i386-CD-14.iso выдал нижеследующее
    md5sum:debian-40r1-i386-CD-14.iso: Input/output error
    Видно что образ подпорченный. но что примечательно большинство файлов из него в норме. В самой ISO`шке присутствует файл md5sum.txt в котором есть контрольная сумма на каждый файл диска.
    Может кто подскажет существует ли простой способ увидеть какие из файлов порченные или их не хватает, чтобы не перебирать вручную каждый?

    ОтветитьУдалить
  16. Вообщем блесну:
    md5, sha - хэш функции, чаще используются для проверки, и из гих сложно получить оригинал. sha - вычислительно сложнее.
    т.е. надежность здесь нужны только если вы подозреваете что в дистрибутив что-то встроил злоумышленник.
    Для md5 и sha - доказана ненадежность.
    для чисто проверки на ошибки копирования используются контрольные суммы, например crc32 - очень быстрая весчь(файлы sfv). (сейчас может имеет смысл использовать crc64) - пакет cksfv.

    ОтветитьУдалить
  17. Записывал 3 dvd-видеодиска с одного iso-шника, чексум по Вашему первому варианту у меня оказался провальный. Причём чексум всех 3х дисков идентичен, диски ессно читабельны. Думаю дело в числе блоков, точнее в вычислении его скриптом echo $(( $(ls -l my.iso | awk '{ print $5 }') / 2048 )). Проверил диск утилитой cdck, который в конце мне сказал количество блоков 2046256 (Ваш скрипт написал о iso-шнике 2046177). После повторения операции с dd с указанием количества блоков от cdck чексум совпадает. Вы можете это объяснить?

    ОтветитьУдалить
  18. Пордон, всё-таки не совпадают. Кстати, если записать диск меньше 1 Гб, то сумма совпадает. Что могло быть не так?

    ОтветитьУдалить
  19. ответ на поставленный мной вопрос оказался довольно прост. Захожу на папку с дебейном св /mnt/cdrom/ и ввожу md5sum -c md5sum.txt и в получаемом консольном выводе разу видно по надписям все нормальные "-OK".
    Создать такой файлик тоже просто, лишь в каталоге будущего диска ввести "find .>md5sum.txt".
    Метод хорош для детальной сверки целостности каждого файла, хотя он и более медлителен.

    ОтветитьУдалить
  20. Если надо убедиться, что все файлы считываются, то:

    cp -rf /mnt/cdrom temp.dir

    ОтветитьУдалить
  21. Кстати, утилита dd уже правильно считает контрольную сумму для записанной болванки без указания размеров блока.

    Команды

    dd if=/dev/cdrom | md5sum

    и

    md5sum ./image.iso

    для записанной болванки и её образа на винте дают одинаковый результат.

    ОтветитьУдалить
  22. Столько способов для такого простого действия. Большое спасибо автору статьи и всем остальным. Помогло даже мне :)

    ОтветитьУдалить
  23. Немного не по теме, но к вопросу о контрольных суммах.
    Создадим директорию
    $mkdir samedir

    В ней создадим файл
    $touch samefile

    Теперь создадим образ iso из полученной директории
    $genisoimage -R -J -o sameiso.iso samedir

    И посчитаем для созданного образа контрольную сумму
    $md5sum -b sameiso.iso

    Так вот, если две последние команды выполнять несколько раз подряд, то контрольные суммы все время получаются разные.
    Когда заметил первый раз, подумал, образ кривой получился.
    Потом увидел, что контрольная сумма все время меняется.
    Подозреваю, что как-то связано с системными часами, но отчего конкретно зависит - не пойму.
    Можно ли как-то сгенерировать два образа с одинаковыми контрольными суммами? Ведь тот же jigdo тоже генерирует iso из файлов, однако контрольная сумма совпадает с заданной.

    ОтветитьУдалить
  24. Отвечу сам себе.
    Да, действительно, в образе iso присутствует информация о времени создания. Это видно в дампе, а также указано в описании стандарта.
    Поэтому сгенерировать два образа с одинаковой контрольной суммой так просто не удастся. В общем-то, это и не нужно. Просто нужно понимать, почему контрольные суммы отличаются.

    Добавлю от себя несколько слов о проверке контрольных сумм при записи образов DVD. Я рассматриваю случай, когда команды вводятся вручную, без использования скрипта.
    При проверке с помощью команды dd данные подаются на вход md5sum, таким образом, посчитанные контрольные суммы приходится сверять визуально, что не очень удобно.
    Я воспользовался таким способом:
    1. Создаем файл-очередь

    mkfifo /tmp/disk1.fifo

    2.Создаем образ для записи на диск. Здесь предполагается, что файлы для записи помещены в одну папку disk.

    genisoimage -R -J -o - disk | tee /tmp/disk1.iso >/tmp/disk1.fifo &

    md5sum -b /tmp/disk1.fifo >/tmp/disk1.md5

    первая команда генерирует образ и направляет данные на вход команды tee, которая перенаправляет их на два потока: в iso-файл и в файл очередь, откуда они попадают на вход md5sum. Генерируется образ и одновременно подсчитывается контрольная сумма.

    3. Далее записываем образ на болванку любым удобным способом.
    После записи болванки необходимо проверить контрольную сумму.
    4. Получаем количество значащих блоков для проверки
    ll --block-size=2048 /tmp/disk1.iso
    5. Используем dd для считывания данных с диска
    dd if=/dev/sr0 bs=2048 count=количество_блоков of=/tmp/disk1.fifo 2>/dev/null &
    md5sum -c /tmp/disk1.md5
    Получаем стандартное сообщение md5sum

    /tmp/disk1.fifo ЦЕЛ

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

    ОтветитьУдалить
  25. Как восстановить исходный .iso-образ из которого был записан DVD, так чтобы даже сошлись суммы md5? Просто взять и создать .iso-образ не получаеться, суммы разные....

    ОтветитьУдалить
  26. [b]Как восстановить исходный .iso-образ из которого был записан DVD, так чтобы даже сошлись суммы md5?[/b]

    Я чуть выше писал, что в iso-файле содержится временной штамп - дата и время создания. Этого достаточно, чтобы суммы не сошлись. Поэтому стандартными средствами, скорее всего, не получится.

    Можно попытаться залезть в потроха DVD-диска и вытащить информацию из спец. полей, а потом внести соответствующие изменения в iso-файл...
    Только стоит ли оно того?

    ОтветитьУдалить
  27. если нужна gui оболочка для вычисления контрольных сумм я пользуюсь
    http://gtkhash.sourceforge.net/
    там все просто
    выбрал файл
    нажал кнопку получил ответ

    ОтветитьУдалить
  28. Да, автором описаны методы, имеющиеся на 2006 год как понимаю, и выглядят они конечно очень извращенно:) Прочитав их я ушел искать другой способ, современный:) Нашлась программка cdshot, сама крохотная, установки не требует, запускаете, указываете привод, ждете пару минут, получаете все необходимые контрольные суммы. Есть один нюанс, для корректной работы нужно чтобы проводник не был запущен, то есть что бы никакие папки не были открыты, иначе программа выдает ошибку. Поэтому создайте ярлычек на рабочем столе и через него запускайте

    ОтветитьУдалить
  29. @Анонимный комментирует...
    Да, автором описаны методы, имеющиеся на 2006 год как понимаю, и выглядят они конечно очень извращенно
    О да, одну команду в консоли написать - это надо быть доктором наук. Это только для избранных.

    Прочитав их я ушел искать другой способ, современный Нашлась программка cdshot
    Анонимус... я даже не знаю, что на это сказать. Ну, понятно, что пост мы не читаем (хотя он на русском), но на название блога-то можно глаза поднять!?

    Эт чё такое-то:

    cdshot.exe 1.64 MБ (1 723 904 байта)

    под винду, да!? Ну и методы, в скотлент-ярде! :-)
    Ты абсолютно беспощаден, Анонимус, я тебе вот что скажу.

    сама крохотная, установки не требует

    БЛОГ ПРО ЛИНУКС, мать его за ногу! ;-) И куда крохотнее-то?

    -rwxr-xr-x 1 root root 22K 2007-01-31 05:51 md5sum

    -rwxr-xr-x 1 root root 38K 2007-01-31 05:51 dd

    60Кб на всё. Так что идите-ка вы со своими "современными" методами и "современными" системами по добру по здорову....

    ОтветитьУдалить
  30. Спасибо, ваша статья очень помогла. Диск, к счастью, записался нормально. хотя у меня были серьёзные сомнения

    ОтветитьУдалить
  31. Есть ещё классная программка dvdisaster, есть в репозитории debian. Она графическая, может считывать контрольные суммы образов, сравнивать, проверять качество записанных дисков. Попробуйте.

    ОтветитьУдалить
  32. попробовал проверить сд с записанным на него systemrescuecd4.5.1 .Выходит,что сд лучше по приведенной методике для двд. ошибки скорей всего от плохого кач-ва сдшек.dmesg выдавал end_request: I/O error, dev sr0, sector 866300. Проверил dd старый записанный alkid на сд, ошибок вв\вывода не было,dmesg спокоен и метод для сд сработал, .Linm@linm-desktop:~$ umount /dev/cdrom
    linm@linm-desktop:~$ sudo dd if=/dev/cdrom | sha1sum
    dd: чтение «/dev/cdrom»: Ошибка ввода/вывода
    866296+0 записей получено
    866296+0 записей отправлено
    скопировано 443543552 байта (444 MB), 97,8822 c, 4,5 MB/c
    dc90448649068d17e66e205400532cf980dea291 -
    linm@linm-desktop:~$ dd if=/dev/cdrom bs=2048 count=216573 | sha1sum
    216573+0 записей получено
    216573+0 записей отправлено
    скопировано 443541504 байта (444 MB), 98,1283 c, 4,5 MB/c
    93e689d218f412d0096da26053ea9828aa5dc7b6 -
    linm@linm-desktop:~$ cd ~/Загрузки/ && sha1sum *.iso
    93e689d218f412d0096da26053ea9828aa5dc7b6 systemrescuecd-x86-4.5.1.iso
    linm@linm-desktop:~/Загрузки$ echo $(( $(ls -l *.iso | awk '{ print $5 }') / 2048 ))
    216573

    после этого проверил dd старый записанный alkid на сд, ошибок вв\вывода не было,dmesg спокоен и метод для сд сработал

    ОтветитьУдалить