Полигон-2

SL project написал:

[q]

20 гиг оно и есть 20 гиг. Эти 18.5 гиг музла спокойно помещались на 20 гиговом винте. Откуда его было решено слить на ленту.
...
тогда чем отличаются 20 гигов винта от 20 гигов кассеты?

Когда то пробовал заархивировать фильм. Ну стал побольше НО там что то смешное было. сколько то килобайт наросло и это с 700 мегового файла.

Не может быть что размер музла увеличился в две раза при запихивании его на ленту.

[/q]

1) Ларчик-то открывается просто: не путай форматированную ёмкость винча и неформатированную ёмкость ленты! Без формата твой винч имеет ёмкость около 28гиг!
2) контроллер стримера (или его дрова, тулза записи) сжимает поток пофайлово, в формат bzip (приблизительно), что даёт прирост размера каждого файла до 200-300К, ибо включает избыточную инфу для коррекции/восстановления архива. Плюс к тому, DDS пишет на ленту только по-кадрово, т.е. уже архивированный файл нарубается на малые куски, и каждый кусок сопровождается служебной и восстановительной инфой, что в размере может достигать 10К/кадр. (форумчане и вЫкипедия поправят, ежли я неточен в цифре, не в этом суть) Теперь посчитай, сколько кадров займёт 3-метровая эмпетришка и посчитай расходы на разметку ленты под неё.
Если от потокового сжатия (а-ля zip) ты сможешь отказаться, то разметочной инфы не избежишь никак, эт тебе не "мафон" с "ласковым маем" на завалинке, в тёплый весенний вечер... С неоднократно зажёванной ленты поющий...
PS. Читать стоит: "лента, тип такой-то, неформатированная ёмкость = 20 гигабайт, при условии сжатия потока данных - до 40 гигабайт". Иллюзия "обмана" исчезла, заметил?

файл в 40 гиг может уместиться и в 512-и байтах винчового сектора. Но только спецом подготовленный файл, а не любой подряд.
Свою кучу музла сожми таром (гугли bsdtar), получишь один файл на 18 гиг, его и лей в стримак. Протестишь емкость, и в дальнейшем пригодится: тулза пашет под виндой.
Гы Какой собакен тебе ленту погрыз?
PS. А твоя тулза пишет на ленту все подряд, или для каждого файла открывает новую сессию записи? Меж сессиями всегда образуются значительного размера дыры, а когда сессий много... ужас!

2:1 сжатие — это рекламный ход, и достигается сильно не всегда

А 20, как уже рассказали — это "неформатированная" емкость.

В целом — чем меньше размер блока при записи, тем меньше полезная емкость.

SL project написал:

[q]

но я же разом пишу. так что если сессия то одна. с чего бы это один файл одна сессия.

[/q]

Команда на запись дана один раз, но это вовсе не значит, что все файлы будут склеены друг с другом в одну длинную цепочку и в таком виде - залиты на ленту. Более того, при таком подходе нет контроля объёма входных данных, и если длина цепочки файлов превысит объём ленты - не будет записан НИ ОДИН файл - процедура окончится неудачей раньше, чем будет записано оглавление ленты.
Если твои файлы всё-ж записаны и читаются, значит каждый из них записан в своей сессии: "перемотка к концу ленты в поиске свободного места->запись файла->перемотка в начало ленты->обновление оглавления". Часто оглавление кешируется, чтоб не мотать лишний раз ленту, однако файлы и в сём случае НЕ соприкасаются байтами - всегда есть некий промежуток, потерянное на закрытие+открытие сессии пространство ленты. Получается подобие ёлочной гирлянды: лампочка == массив данных за сессию, провода меж ними == потерянное на межсессионные нужды пространство.