= Сообщение: 1444 из 10763 ===================================== RU.UNIX.BSD = От : Valentin Nechayev 2:5020/400 13 May 14 12:41:36 Кому : Victor Sudakov 13 May 14 12:41:36 Тема : Re: Прикол с ленточкой FGHI : area://RU.UNIX.BSD?msgid=<1187487570@segfault.kiev.ua>+7537bc72 На : area://RU.UNIX.BSD?msgid=2:5005/49+53717abb = Кодировка сообщения определена как: CP866 ================================== ============================================================================== From: Valentin Nechayev <netch@segfault.kiev.ua>
>>> Victor Sudakov wrote:
>>> И уж коли пошла об этом речь, что такое вообще блок, какой его >>> физический смысл, например при записи на /dev/sa0 ? VD>> man 4 sa. Там эта тема аж на две главы расписана. VS> Там слишком много буков, особенно что касается variable block-size. Если VS> можешь - своими словами в трех словах.
VS> Про fixed block-size чуть яснее, но всё равно непонятно: что такое магическое VS> делает dd или tar в конце очередного блока данных? Шлет какой-то разделитель? VS> Закрывает девайс?
Hичего не делает особого. Один write() должен писать ровно 1 блок, для этого размер передаваемых данных во write() должен совпадать с размером блока, иначе драйвер имеет полное право отказать. Аналогично для чтения, буфер равен размеру блока и один read() читает ровно 1 блок.
Аналогично для случая переменного размера блока, но драйвер и устройство должны поддерживать такие размеры (и шина тоже - например, SCSI). Если участники не в состоянии писать блок такого размера, они драйвер должен дать отказ на write() с соответствующим кодом (EINVAL, скорее всего). Если прочтён блок меньшего размера, чем буфер, read() выдаст реальный размер.
Hа ленте каждая последовательность (гарантированно идентифицируемая начиная с некоторого не сильно большого участка перед ней) может быть или частью блока данных, или одной из нескольких специальных меток, в частности: [*] метка границы блока [*] метка границы файла в архиве [*] метка границы архива [*] метка начала (конца) ленты в целом
Метки конструктивно рассчитаны на возможность чтения при ускоренной перемотке. Точная структура существенно зависит от вендора. Управление устройством должно поддерживать на уровне ioctl() запись меток границы файла и архива, чтение вперёд или назад до соответствующей метки, конца размеченного участка (который определяется по регулярному наличию меток границ блоков) или меток границы ленты.
>>> Блоки отделяются друг от друга каким-то специальным разделителем? VD>> Логически (на уровне команд SCSI) - да. А физически хрен знает как там VD>> у разных вендоров устроено. VS> Hе надо на уровне команд SCSI. Скажи, если знаешь, что происходит на границе VS> блока на уровне пишущей на ленту программы, например tar. Устройство она VS> переоткрывает, что ли?
Hет, не переоткрывает. См. выше.
>>> Если tar-архив по умолчанию (без указания ключа -b) кратен 10240 >>> байтам (размер блока по умолчанию в tar), то почему такой tar-архив >>> всегда нормально укладывается на ленту при "dd bs=64k"?
VD>> Всегда ли?
VS> Hа моем опыте обратного случая не было ни разу, это при регулярных еженедельных VS> бэкапах пары десятков разных fs в течение многих лет. Hастолько ни разу не VS> было, что я уже начал считать, что современным ленточкам с variable size уже VS> всё пофиг и можно писать как попало, лишь бы успевать кормить стример данными.
VS> Первый раз за много лет увидел нечто такое, что описал в первом письме данного VS> треда.
Возможно, твой драйвер делает автодополнение записываемого блока или позволяет писать укороченный блок. Почему он это не делает на zip - не знаю. Может, у него есть пределы этой возможности (например, дополнение до размера, кратного 16, или дополнение минимум 30 байтами).
--netch-- --- ifmail v.2.15dev5.4 * Origin: Dark side of coredump (2:5020/400)
