Цель ibs/obs/bs в dd

Для чтения из / dev / zero это не имеет значения. ibs / obs / bs указывает, сколько байтов будет прочитано за раз. Целесообразно выбирать число в зависимости от способа чтения / записи байтов в операционной системе. Например, Linux обычно читает с жесткого диска порциями по 4096 байт. Если у вас есть хоть какое-то представление о том, как базовое оборудование читает / записывает, было бы неплохо указать ibs / obs / bs. Кстати, если вы укажете bs, он переопределит все, что вы укажете для ibs и obs.

Чтобы понять размеры блоков, вы должны быть знакомы с ленточными накопителями. Если вас не интересуют ленточные накопители - например, вы не думаете, что когда-нибудь собираетесь их использовать - тогда можете снова заснуть.

Вспомните ленточные накопители из фильмов 60-х, 70-х годов. , может, даже 80-е? Те, где катушка крутилась и так далее? Ни ваш Exabyte, ни даже QIC - кассеты с четвертьдюймовым картриджем; ваши старые добрые полудюймовые ленточные накопители с катушкой на катушку? В этом случае размер блока имел значение.

Данные на ленте записывались блоками. Каждый блок был отделен от следующего промежутком между записями.

----+-------+-----+-------+-----+----
... | block | IRG | block | IRG | ...
----+-------+-----+-------+-----+----

В зависимости от аппаратного и программного обеспечения ленточного накопителя могло произойти множество проблем. Например, если лента была записана с размером блока 5120 байт, и вы читаете ленту с размером блока 512 байт, то ленточный накопитель может прочитать первый блок, вернуть вам его 512 байт, а затем отбросить оставшиеся данные; следующее чтение начнется в следующем блоке. И наоборот, если лента была записана с размером блока 512 байт, и вы запросили блоки размером 5120 байт, вы получите короткие чтения; каждое чтение возвращало бы всего 512 байт, и если бы ваше программное обеспечение не обращало внимания, вы бы читали мусор. Также была проблема, что ленточный накопитель должен был набрать скорость, чтобы прочитать блок, а затем замедлился. Искусство ASCII предполагает, что IRG был меньше блоков данных; это не обязательно так. И потребовалось время, чтобы прочитать один блок, выйти за пределы IRG, перемотать назад, чтобы перейти к следующему блоку, и снова начать движение вперед. А если у ленточного накопителя не было памяти для буферизации данных - у более дешевых - нет - тогда вы могли бы серьезно повлиять на производительность ленточного накопителя.

Военная история: подготовка к работе на новой машине с немного более современным ленточным накопителем. Я написал ленту с использованием tar без разумного размера блока (поэтому по умолчанию было 512 байт). Это была большая часть программного обеспечения - должно быть, всего меньше 100 МБ (другими словами, очень давно). Лента записывалась хорошо, потому что машина была достаточно современной, а на это ушло всего несколько секунд. Но мне пришлось снять материал с ленты на машине со старым ленточным накопителем, у которого не было встроенного буфера. Итак, он прочитал материал по 512 байтов за раз, и барабан покачнулся вперед, прочитав один блок, а затем качнулся назад почти на полдюйма, а затем читать вперед, чтобы перейти к следующему блоку, а затем качнулся назад, и ... ну, вы могли видеть, как он это делает, и поскольку для чтения каждого 512-байтового блока потребовались заметные доли секунды, общее затраченное время было ужасно. Мой рейс должен был вылететь ... и мне тоже нужно было передать эти данные. (Это было достаточно давно и на достаточно далекой земле, поэтому изменение полетов в последнюю минуту тоже было не лучшим вариантом.) Короче говоря, это действительно было прочитано - но если бы я использовал разумного размера блока (например, 5120 байт вместо 512 по умолчанию), я бы сделал это намного, намного быстрее и с гораздо меньшей опасностью пропустить самолет (но я действительно успел на самолет, возможно, у меня осталось 20 минут, несмотря на поездку на такси по Парижу в час пик).

С более современными ленточными накопителями, на накопителе было достаточно памяти, чтобы выполнить буферизацию и заставить ленточный накопитель передавать поток - непрерывную запись без реверсирования - было возможно. Раньше я использовал размер блока, например 256 КБ, для передачи лент QIC в поток. В последнее время я мало что сделал с ленточными накопителями - давайте посмотрим, не в этом тысячелетии и не так много за несколько лет до этого; конечно, не так много, поскольку CD и DVD стали предпочтительными механизмами распространения программного обеспечения (когда электронная загрузка не использовалась).

Но размер блока действительно имел значение в старые времена. И dd оказал ему хорошую поддержку. Вы даже можете передавать данные с ленточного накопителя, который был записан, например, блоком 4 КБ, на другой, который вы хотели записать, например, блоками по 16 КБ, указав ibs (размер входного блока) отдельно от obs (размер выходного блока). Чертовски полезно!

Кроме того, параметр count относится к размеру (входного) блока. Было полезно сказать « dd bs = 1024 count = 1024 if = / dev / zero of = / my / file / of / zeroes », чтобы скопировать 1 МБ нулей вокруг. Или скопировать 1 МБ файла.

Значение dd значительно уменьшилось; он был важной частью арсенала для всех, кто работал с ленточными накопителями десять или более лет назад.

Значение dd значительно уменьшилось; это была важная часть арсенала для всех, кто работал с ленточными накопителями десять или более лет назад.

Значение dd значительно уменьшилось; он был важной частью арсенала для всех, кто работал с ленточными накопителями десять или более лет назад.