Создайте Случайный ISO-образ Используя dd
Вы могли непреднамеренно, чтобы согласиться загрузить и установить огромный набор зависимостей (например, если Вы хотите установить программу KDE на машине, где никакой KDE не установлен).
Так как Вы пишете в файл с dd, размер блока не изменит получающийся вывод. Размер блока только имеет значение при записи в устройства.
Вы читаете из устройства, которое никогда не будет возвращать короткие чтения, таким образом, Вы не должны будете использовать sync заполнять блоки.
В любом случае, dd не имеет доступа для чтения или доступа для записи к данным коррекции ошибок. Как с магнитными носителями, диск управляет теми данными, и Вы видите только исправленные ошибкой блоки.
-
1Спасибо за Вас справка. Это имеет намного больше смысла теперь. Причина я указал размер блока, состоит в том, потому что я указал количество, таким образом, размер блока будет влиять на объем данных, я добираюсь, не так ли? – robingrindrod 14.09.2012, 18:27
-
2При записи непосредственно в CD, размер блока является только вопросом производительности. Размер блока имеет значение только при записи в накопители на магнитной ленте. – Gilles 'SO- stop being evil' 15.09.2012, 02:35
На основе то, что Вы описали Вас, должно сделать что-то вроде этого:
dd if=/dev/urandom of=testfile bs=1M count=699
mkisofs -o test_cdrom.iso testfile
После того, как сделанный можно читать и записать в и от оптических сред до содержания основ.
Одна вещь, которую я предложил бы, состоит в том, что вместо того, чтобы предварительно тестировать оптические среды и затем пытаться записать фактический ISO и затем проверяя, что Вы могли бы также записать целевым данным ISO однажды, так как это даст Вам тот же самый результат, как Вы пытаетесь достигнуть, не проводя время на Write->Read->Verify->Format
Создание изображения, сделанного из случайных байтов, не является хорошей идеей, потому что оно приводит к очевидно недопустимой файловой системе ISO 9660. Необходимо вместо этого создать большой случайный файл, который может все еще быть помещен в допустимой файловой системе ISO. Затем Вы записываете этот ISO-образ и читаете содержание CD для сравнения с исходным файлом на жестком диске, например, с также md5sum или sha1sum. Если контрольные суммы являются тем же, то Ваш диск в порядке и в пишущих и в читающих CD.
-
1Очень цените свою справку. Вы возражали бы разъяснять, почему имеет значение, если данные являются допустимой файловой системой ISO 9600. Все, чем я действительно интересуюсь, является необработанными данными и читается ли это правильно. – robingrindrod 15.09.2012, 14:52
-
2Сначала, я думал, что программа для записи дисков CD могла отказаться писать недопустимый ISO-образ, но это кажется им, не имеет место. Просто не добавляйте к случайному файлу изображения
.isoсуффикс, потому что это не файловая система ISO 9660. Так или иначе при сравнении ISO-образов вместо содержания ISO-образов, у Вас могут быть незначительные проблемы с байтами конечного нуля (см. это для деталей). – Francesco Turco 15.09.2012, 15:37 -
3Спасибо за подсказку о конечных нулях. У Вас есть какая-либо идея, что вызывает это? Также сделайте у Вас есть источник, чтобы проверить, что ISO-образы могут только содержать файловые системы ISO 9660, поскольку страница Wikipedia указывает, что "Имя ISO взят от файловой системы ISO 9660, используемой с медиа CD-ROM, но что известно, поскольку ISO-образ мог бы также содержать UDF (ISO/IEC 13346) файловая система или DVD или изображение Диска Blu-ray (BD)". – robingrindrod 15.09.2012, 16:09
-
4К сожалению, я не знаю то, что вызывает присутствие конечных нулей. Что касается изображений кроме файловых систем ISO 9660, я никогда не видел их. Но полагайте, что я не эксперт. Поэтому давайте ожидать и давайте посмотрим, знает ли кто-то еще больше, чем мы. – Francesco Turco 15.09.2012, 23:29
-
5Это сообщение упоминает, что конечные нули могли бы увеличить последний блок, если данные не соответствуют равномерно блокам. Это то, к чему Вы обращались, или Вы испытали дополнительные блоки, заполненные нулями? – robingrindrod 16.09.2012, 16:24