Vadim |
|
Темы:
280
Сообщения:
1909
Участник с: 20 ноября 2013
|
извиняюсь что влез,у меня почему-то старые,пролежавшие несколько лет диски почему-то намного хуже читаются чем когда их записывал. проверял на разных компьютерах,результат один. хранились в коробочках или специальной сумочке,в темном месте,при комнатной температуре и тем не менее. на hdd по моему намного лучше все сохраняется,особенно если он не постоянно в работе. еще раз извиняюсь.
Linux Forever!
|
akorop |
|
Темы:
111
Сообщения:
1755
Участник с: 29 февраля 2012
|
anodelsblk -bn -o FSSIZE /dev/sr0 даёт то же самое, только в байтах, а не в секторах. Но беда в том, что iso разные бывают. Скажем, для арч-диска (созданного при помощи archiso) эта длина совпадает с длиной iso-файла. А для iso, созданного разными (старенькими, впрочем) средствами ubuntu, iso-файл длиннее. На глаз, это удлинение всё заполнено нулями - вероятно, это lead-out.akoropПроверить не могу за неимением, Тут говорят, что так Похоже, что считать контрольную сумму диска только до длины, которую выдают isoinfo или lsblk, - это правильно. Но тогда и контрольную сумму iso тоже надо считать только до этой длины, а не до полной длины файла, вместе со всеми нулями. В общем, немного в голове прояснилось. Спасибо всем за подсказки. Наверно, адаптирую свой скрипт для КС диска, чтобы он и КС iso-файла мог считать (до логической длины данных). А isomd5sum использовать хочется, но страшно. Очень уж она "вещь в себе". |
akorop |
|
Темы:
111
Сообщения:
1755
Участник с: 29 февраля 2012
|
Вот результат, на котором я останавливаюсь. dvd_md5
|
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
Чисто профессиональное любопытство - не понятно назначение проверки целостности CD/DVD, точнее, какая коренная причина этого? Обычно проверка целостности CD/DVD не имеет смысла. Если имеется ввиду сохранность информации, то в случае не совпадения контрольной суммы это никак не говорит о том, что информация потеряна. Во многих случаях ее можно вытащить. CD/DVD уникальны тем, что они устроены так, что информация на них очень избыточна - то есть извлечь из них полезную информацию при не читаемости диска намного эффективнее, чем на HDD. Но возможна и такая ситуация, контрольная сумма совпадает, но диск не читается, но это тоже решаемо - вот поэтому и интересна причина этих проверок. В части размера диска, в случае вопросов можно использовать cdrecord, которая более информативна (привожу концовку вывода) cdrecord -media-info И для сравнения вывод isoinfoisoinfo -d -i /dev/cdrom | grep -i -E 'block size|volume size'
Кстати, размер (да и количество зон) leadout может быть разным - зависит от количества записанных сессий. Но вот влияет ли это на размер iso - как то никогда не интересовался. ... и обрати внимание на leadout в выводе cdrecord EDIT 1 - в части нулей akoropleadout не пустой - он содержит инфомацию, а после, на свободном месте идут уже нули. И если уж считать, то нужно отбрасывать все сектора leadout (а это несколько тысяч) EDIT 2 - и если будешь делать образ диска, то лучше это делать через dd - dd if=/dev/cdrom of=name.iso bs=2048
Ошибки не исчезают с опытом - они просто умнеют
|
nafanja |
|
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
vasekа как можно узнать контрольную сумму не прочитав данные??? просто контрольная сумма зависит от данных, если данные не читаемы то и никакую сумму не вычислить...
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
nafanjaХотел на деда на ехать? - шутка ))) Давай расмотрим упрощенный формат CD/DVD, который содержит 3 области - lead-in (размер 4500 секторов) - служебная информация о диске и записи - date - полезная информация, информация записанная юзером на диск - lead-out (размер 6750 секторов, но есть нюансы) - служебная информация об окончании записи Компьютер видит только область date, больше ему не позволено. Смотрим вывод приведенный мной выше cdrecord -media-info Посмторим более детально на эту область date- 16 секторов (32768 байт) как правило не заняты - одни нули hexdump -C -n 32768 /dev/sr0 Начало 17 сектора содержит идентификатор CD001 (а если диск к тому загрузочный, то добавляется иденнтификатор El TORITO SPECIFICATION)hexdump -C -s 32768 -n 16 /dev/sr0
И если CD-устройство не cможет считать, например, область lead-in, то диск прочитать будет не возможно, хотя контрольная сумма не изменилась.
Ошибки не исчезают с опытом - они просто умнеют
|
akorop |
|
Темы:
111
Сообщения:
1755
Участник с: 29 февраля 2012
|
vasekПричина очень простая: ГОСТ. Диски хранятся в двух экземплярах (условно называемых подлинником и дубликатом). Если строго по ГОСТу - хранятся в разных зданиях (чтобы не сгорели одновременно). Их положено периодически контролировать (кажется, раз в год). И если какой-то протух - выкинуть его и сделать новый, скопировав с другого, целого. Если вдруг протухли оба одновременно, то должна ещё быть контрольная копия, с неё и воссоздаются умершие подлинник и дубликат. (Контрольная копия делается с подлинника или дубликата, чтобы с неё делать рабочие копии. А сами подлинник и дубликат просто лежат, их нельзя использовать ни для чего, кроме создания контрольной копии). На самый крайний случай - можно воссоздать с рабочей копии. А выковыривать данные с нечитаемого диска - это романтика, которая должна быть начисто исключена. Такой порядок существует не одно десятилетие, и никто его менять не будет. Разве что в принципе прекратят хранение на автономных носителях, а всё будут хранить в датацентрах. |
akorop |
|
Темы:
111
Сообщения:
1755
Участник с: 29 февраля 2012
|
vasekА где про это можно почитать? Илучше, чтобы не упрощённо. |
nafanja |
|
Темы:
94
Сообщения:
9252
Участник с: 02 июня 2012
заблокирован
|
vasek, я все равно не понял (((vasekвот нас интересуют только эти данные. что бы получить например MD5, эти данные нужно прочитать (по другому никак)... нас же не интересует контрольная сумма образа, а только полезной информации... если полезная информация не считывается, по разным причинам, то и контрольную сумму из них нельзя просчитать... уточню, я говорю именно о пользовательской инфе, другая инфа нам не нужна... вывод: если все данные с диска читаются без проблем, то он живой, если есть проблемы, то дохлый!!!
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874 |
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
akoropЕсли не упрощенно, то первоисточники - стандарты, спецификации. Если упрощенно, то раньше было много статей по данной тематике, в том числе и по восстановлению информации. Несколько лет назад делал чистку и многое удалил из того, что уже устарело. Но посмотрю, может что то еще и осталоь.
Ошибки не исчезают с опытом - они просто умнеют
|