Контрольная сумма DVD

извиняюсь что влез,у меня почему-то старые,пролежавшие несколько лет диски почему-то намного хуже читаются чем когда их записывал.
проверял на разных компьютерах,результат один.
хранились в коробочках или специальной сумочке,в темном месте,при комнатной температуре и тем не менее.
на hdd по моему намного лучше все сохраняется,особенно если он не постоянно в работе.
еще раз извиняюсь.
Linux Forever!
anode
akorop
как, имея диск, узнать длину исошки, не записывая исошку?
Проверить не могу за неимением, Тут говорят, что так
isoinfo -d -i /dev/cdrom | grep -i -E 'block size|volume size'
lsblk -bn -o FSSIZE /dev/sr0 даёт то же самое, только в байтах, а не в секторах. Но беда в том, что iso разные бывают. Скажем, для арч-диска (созданного при помощи archiso) эта длина совпадает с длиной iso-файла. А для iso, созданного разными (старенькими, впрочем) средствами ubuntu, iso-файл длиннее. На глаз, это удлинение всё заполнено нулями - вероятно, это lead-out.
Похоже, что считать контрольную сумму диска только до длины, которую выдают isoinfo или lsblk, - это правильно. Но тогда и контрольную сумму iso тоже надо считать только до этой длины, а не до полной длины файла, вместе со всеми нулями.
В общем, немного в голове прояснилось. Спасибо всем за подсказки. Наверно, адаптирую свой скрипт для КС диска, чтобы он и КС iso-файла мог считать (до логической длины данных). А isomd5sum использовать хочется, но страшно. Очень уж она "вещь в себе".
Вот результат, на котором я останавливаюсь.
dvd_md5
#!/bin/bash
#
#    Подсчёт контрольной суммы md5 файла iso или оптического диска.
# Реальная длина файла iso иногда бывает больше той, которую сообщает isoinfo,
# за счёт избыточных нулей в конце, которые ни на что не влияют, за исключением
# контрольной суммы. Поэтому считаем md5sum только для "полезной" длины, так что
# сумма, подсчитанная этим скриптом, может отличаться от суммы, подсчитанной
# "в лоб": md5sum bla-bla.iso. Но зато она всегда совпадает с суммой,
# подсчитанной с диска, который записан по этой iso, независимо от того,
# есть в конце iso лишние нули, или нет.
#   Параметр - имя файла или устройства; если опущен используется /dev/sr0
#
#   Зависимости: isoinfo, grep, cut, md5sum, pv
#
  DISK="$1"
  if [ ! -n "$DISK" ]; then
    DISK="/dev/sr0"
  fi
  BLOCKS=`isoinfo -d -i $DISK 2> /dev/null | grep -i "volume size" | cut -d " " -f 4-4`
  SIZE=$(($BLOCKS * 2048))
  echo "disk $DISK, data size $SIZE bytes"
  dd if=$DISK bs=2048 count=$BLOCKS status=none | pv -s $SIZE | md5sum
Чисто профессиональное любопытство - не понятно назначение проверки целостности CD/DVD, точнее, какая коренная причина этого?
Обычно проверка целостности CD/DVD не имеет смысла.
Если имеется ввиду сохранность информации, то в случае не совпадения контрольной суммы это никак не говорит о том, что информация потеряна. Во многих случаях ее можно вытащить. CD/DVD уникальны тем, что они устроены так, что информация на них очень избыточна - то есть извлечь из них полезную информацию при не читаемости диска намного эффективнее, чем на HDD.
Но возможна и такая ситуация, контрольная сумма совпадает, но диск не читается, но это тоже решаемо - вот поэтому и интересна причина этих проверок.

В части размера диска, в случае вопросов можно использовать cdrecord, которая более информативна (привожу концовку вывода)
cdrecord -media-info
Track  Sess Type   Start Addr End  Addr   Size
=====================================
    1     1       Data     0    1415631     1415632

Last session start address:             0
Last session leadout start address: 1415632
И для сравнения вывод isoinfo
isoinfo -d -i /dev/cdrom | grep -i -E 'block size|volume size'
Setting input-charset to 'UTF-8' from locale.
Logical block size is: 2048
Volume size is: 1415632

Кстати, размер (да и количество зон) leadout может быть разным - зависит от количества записанных сессий. Но вот влияет ли это на размер iso - как то никогда не интересовался. ... и обрати внимание на leadout в выводе cdrecord

EDIT 1 - в части нулей
akorop
На глаз, это удлинение всё заполнено нулями - вероятно, это lead-out.
leadout не пустой - он содержит инфомацию, а после, на свободном месте идут уже нули. И если уж считать, то нужно отбрасывать все сектора leadout (а это несколько тысяч)

EDIT 2 - и если будешь делать образ диска, то лучше это делать через dd - dd if=/dev/cdrom of=name.iso bs=2048
Ошибки не исчезают с опытом - они просто умнеют
vasek
Но возможна и такая ситуация, контрольная сумма совпадает, но диск не читается, но это тоже решаемо - вот поэтому и интересна причина этих проверок.
а как можно узнать контрольную сумму не прочитав данные??? просто контрольная сумма зависит от данных, если данные не читаемы то и никакую сумму не вычислить...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
nafanja
а как можно узнать контрольную сумму не прочитав данные??? просто контрольная сумма зависит от данных, если данные не читаемы то и никакую сумму не вычислить…
Хотел на деда на ехать? - шутка )))
Давай расмотрим упрощенный формат CD/DVD, который содержит 3 области
- lead-in (размер 4500 секторов) - служебная информация о диске и записи
- date - полезная информация, информация записанная юзером на диск
- lead-out (размер 6750 секторов, но есть нюансы) - служебная информация об окончании записи
Компьютер видит только область date, больше ему не позволено. Смотрим вывод приведенный мной выше
cdrecord -media-info
Track  Sess Type   Start Addr End  Addr   Size
=====================================
    1     1       Data     0    1415631     1415632

Last session start address:             0
Last session leadout start address: 1415632
Посмторим более детально на эту область date
- 16 секторов (32768 байт) как правило не заняты - одни нули
hexdump -C -n 32768 /dev/sr0
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00008000
Начало 17 сектора содержит идентификатор CD001 (а если диск к тому загрузочный, то добавляется иденнтификатор El TORITO SPECIFICATION)
hexdump -C -s 32768 -n 16 /dev/sr0
00008000  01 43 44 30 30 31 01 00  20 20 20 20 20 20 20 20  |.CD001..        |
00008010

И если CD-устройство не cможет считать, например, область lead-in, то диск прочитать будет не возможно, хотя контрольная сумма не изменилась.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Чисто профессиональное любопытство - не понятно назначение проверки целостности CD/DVD, точнее, какая коренная причина этого?
Обычно проверка целостности CD/DVD не имеет смысла.
Причина очень простая: ГОСТ.
Диски хранятся в двух экземплярах (условно называемых подлинником и дубликатом). Если строго по ГОСТу - хранятся в разных зданиях (чтобы не сгорели одновременно). Их положено периодически контролировать (кажется, раз в год). И если какой-то протух - выкинуть его и сделать новый, скопировав с другого, целого. Если вдруг протухли оба одновременно, то должна ещё быть контрольная копия, с неё и воссоздаются умершие подлинник и дубликат. (Контрольная копия делается с подлинника или дубликата, чтобы с неё делать рабочие копии. А сами подлинник и дубликат просто лежат, их нельзя использовать ни для чего, кроме создания контрольной копии). На самый крайний случай - можно воссоздать с рабочей копии. А выковыривать данные с нечитаемого диска - это романтика, которая должна быть начисто исключена.
Такой порядок существует не одно десятилетие, и никто его менять не будет. Разве что в принципе прекратят хранение на автономных носителях, а всё будут хранить в датацентрах.
vasek
Давай расмотрим упрощенный формат CD/DVD, который содержит 3 области
А где про это можно почитать? Илучше, чтобы не упрощённо.
vasek, я все равно не понял (((
vasek
- date - полезная информация, информация записанная юзером на диск
вот нас интересуют только эти данные. что бы получить например MD5, эти данные нужно прочитать (по другому никак)...
нас же не интересует контрольная сумма образа, а только полезной информации... если полезная информация не считывается, по разным причинам, то и контрольную сумму из них нельзя просчитать...
уточню, я говорю именно о пользовательской инфе, другая инфа нам не нужна...
вывод: если все данные с диска читаются без проблем, то он живой, если есть проблемы, то дохлый!!!
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
akorop
А где про это можно почитать? Илучше, чтобы не упрощённо.
Если не упрощенно, то первоисточники - стандарты, спецификации. Если упрощенно, то раньше было много статей по данной тематике, в том числе и по восстановлению информации. Несколько лет назад делал чистку и многое удалил из того, что уже устарело. Но посмотрю, может что то еще и осталоь.
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.