четверг, Ноябрь 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.

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

CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.72-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0xf49 Stepping = 9
AMD Features=0x20100000
AMD Features2=0x1
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 - смысл одинаков, скорость всё равно ограничена железом.


Проверка правильности записи на 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) *
Выделенные полужирным цифры и подставляем в качестве цели для записи - это наш привод.

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

Копируете статью - поставьте ссылку на оригинал!

20 комментариев:

jankkhvej комментирует...

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

virens комментирует...

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

kri комментирует...

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

virens комментирует...

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

kri комментирует...

Понятно.

jankkhvej комментирует...

Насчёт смысла 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 - смысл одинаков, скорость всё равно ограничена железом.

virens комментирует...

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

ram32 комментирует...

большое спасибо за статью - очень помогла! =)

Mebius комментирует...

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

giner комментирует...

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

Анонимный комментирует...

или даже так
md5sum /dev/cdrom

giner комментирует...

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

virens комментирует...

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

Alexander Artemenko комментирует...

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

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

virens комментирует...

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

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

bok комментирует...

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

Анонимный комментирует...

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

Анонимный комментирует...

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

Анонимный комментирует...

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

altutov комментирует...

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

Отправить комментарий