LINUX.ORG.RU
ФорумTalks

Почему минимальный tar aрхив занимает нехилых 10Кб ?

 ,


0

1

Собственно сабж.

# tar --version | grep tar
tar (GNU tar) 1.23

# echo 123 >123.txt
# tar -cf 123.tar 123.txt
# zip -0 123.zip 123.txt
  adding: 123.txt (stored 0%)

# ls -l
итого 16
-rw-rw-r-- 1 root root 10240 Авг 30 16:36 123.tar
-rw-rw-r-- 1 root root     4 Авг 30 16:35 123.txt
-rw-rw-r-- 1 root root   168 Авг 30 16:42 123.zip

Если создавать пустой - всё те же 10Кб

Пишу в talks ибо вопрос больше из любопытства

★★★
Ответ на: комментарий от bhfq

вранье. добавится заголовок, 2 блока в конце и выравнивание < 512. итого < 2 кб

chg ★★★★★
()
Ответ на: комментарий от TEX

Я нихера не понял. Причём здесь физический сектор ленты (которого не существует)? Откуда ты взял промежуток в 10Кб? 10Кб - это размер записи по умолчанию.

redgremlin ★★★★★
()
Ответ на: комментарий от q11q11

игруля в 40кил занимала 5 минут прослушивания

То есть плотность ленты занимала 40Кб / 5*60 = 40960*8 / 300 = ~ 136 бит на секунду записи.

Допустить что лентопротягу нужно 5*60/4 = 75 секунд что бы только лишь точно спозиционироваться на отрезок данных - это насиловать мою, и думаю всех остальных, светлую память.

TEX ★★★
() автор топика
Ответ на: комментарий от redgremlin

Я нихера не понял. Причём здесь физический сектор ленты (которого не существует)?

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

Откуда ты взял промежуток в 10Кб? 10Кб - это размер записи по умолчанию.

Именно оттуда и взял. Из размера record по умолчанию 20*512 - вопрос в том нафига он такой огромный ?

TEX ★★★
() автор топика
Ответ на: комментарий от chg

минимальный tar должен занимать 512 байт на заголовок, тело с выравниванием по 512, то есть 123 это еще 512 и два блока-заполнителя в конце, еще 1024. итого 2 кб.

Да не вопрос - в вашем дистрибутиве вышеприведенный пример сколько занимает ?

zip здесь за каким хреном?

Для примера как должен себя вести архиватор. Или хотя бы пытаться.

TEX ★★★
() автор топика
Ответ на: комментарий от TEX

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

1. Это _не_минимальный_ размер
2. К позиционированию размер записи тоже отношения не имеет

Именно оттуда и взял

Ты не догоняешь. Промежуток между записями от размера записи не зависит никак. Ниже попробую объяснить на пальцах.

Из размера record по умолчанию 20*512 - вопрос в том нафига он такой огромный ?

Для современных лент рекомендуют вплоть до 256 блоков в записи, вообще-то.

А теперь на пальцах:
Допустим, надо считать с ленты архив. Тут мы сталкиваемся с
1. Архив может быть на много-много гигабайт. Столько, сколько в память не влезет
2. Лента крутится механизмами и мгновенно остановиться не может
3. Считываться архив может куда угодно, вплоть до нанободного модемного соединения на Марс
поэтому tar читает не весь архив целиком, а относительно небольшую запись, после прочтения записи останавливает ленту, чтобы дать возможность обработать эту запись, далее пускает ленту снова и всё повторяется. Таким образом, между моментами окончания чтения одно записи и началом другой есть небольшой интервал времени, в котором лента движется, но не считывается. Вот для того, чтобы в этом интервале не было никаких данных и создается промежуток тишины между записями.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

А теперь на пальцах:

1. Да

2. Да

3. Буферизацию и поблочное считывание никто не отменял

Ответа какой смысл делать минимальный архив tar в 10Кб по прежнему нет. По приведенной ссылке написано что мол если сделать больше то старые версии tar могут навернуться, но у меня ровно обратный вопрос, почему не сделать меньше ?

TEX ★★★
() автор топика
Ответ на: комментарий от TEX

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

Мне кажется промежутки между записями вообще контролируются исключительно самим лентопротягом. Это его головная боль, определить что кончился один блок данных и начался новый.

TEX ★★★
() автор топика
Ответ на: комментарий от TEX

Буферизацию и поблочное считывание никто не отменял

Вот поэтому и идёт позаписьное считываение.

Ответа какой смысл делать минимальный архив tar в 10Кб по прежнему нет

Он дан давным давно - «historical reasons». Когда-то эта цифра имела какой-то смысл. Сейчас она ни какого смысла не несёт, но должен же быть какой-то дефолт, почему не оставить старый добрый и всем привычный?

почему не сделать меньше

Потому что тогда на ленту влезать меньше будет из-за вышерасписанных служебных промежутков. Вот и советуют, в зависимости от оборудования, делать 96, 112, 126, 256 блоков в записи. Ну или 32 для большей совместимости. Или дефолтные 20 для поддержки всегда и везде, даже на самых древних тарах.

redgremlin ★★★★★
()

Потому, что тар - убогий недоформат, используемый не по назначению, чья распространённость - лишнее подтверждение извращённости нашего мира. Хуже него только зип.

Legioner ★★★★★
()
Ответ на: комментарий от TEX

1. Физический сектор ленты не равен 10Кб

Давно уже не равен. Сейчас он обычно ближе к мегабайту–двум. При этом все современные накопители поддерживают на входе переменный размер блока.

И только дурак или некомпетентный пишет на современные ленты блоками менее одного мегабайта. Архивы на LTO у меня всю жизнь писались с '-b 16384'. Прикинь, архив твоего файлика занимает восемь мегабайт!

2. Зависит от реализации программы

Блок на ленту читается и пишется только целиком. Каждый блок имеет свой индекс, к которому привод умеет перематывать ленту.

Промежуток в 10Кб это дохрена.

Плотность записи на современные ленты порядка 16Kb на миллиметр на дорожку, одновременно в линейных системах пишется 16 дорожек. Это совсем не дохрена при перемотке километра ленты в десять раз тоньше волоса. Ускорение старт/стоп можешь подсчитать самостоятельно.

baka-kun ★★★★★
()
Ответ на: комментарий от TEX

смысл делать минимальный архив tar в 10Кб

Так делает только GNU tar по историческим причинам. BSD tar сделает минимальный стандартный tar-архив: 512b заголовок, 512b первый и единственный блок файла, пустые 2x512b как признак конца архива.

baka-kun ★★★★★
()
Ответ на: комментарий от TEX

у меня zip не установлен. в примере большую часть занимают именно структуры zip, а не tar, который упоминается в заголовке темы.

zip не используют с tar-ом, то есть никогда, так как zip имеет встроенную поддержку файлов и, более того, встроенную поддержку индексов, благодаря чему можно распаковывать отдельные файлы без распаковки всего архива. тарболы такой радости лишены — только линейный поиск или внешний индекс

chg ★★★★★
()
Ответ на: комментарий от mm3

Во времена создания tar под «архивом» понималось структурирование хранения информации и не предполагалось никакого сжатия или экономии пространства, так как этим занимаются другие утилиты.

дык и сейчас не предполагается. Сжатие tar это опциональная фишка, причём такая, которая ломает 80% функционала tar'а. IRL сжатие нафиг не нужно в большинстве случаев. Что ты будешь делать с tar? Просто хранить? А как тогда смотреть/добавлять? Да и что жалеть-то? Шифровать? Ну вот gpg и сожмёт, зачем жать дважды? Отправишь? Ну вот то, что отправляет, за одно и сожмёт. Оно умеет(ssh, apache, etc). Ну и вообще, если тебе надо сжать Over9000 файлов, возьми и сожми Over9000 файлов. Зачем их тарить?

emulek
()
Ответ на: комментарий от true_admin

Создай 18 мб файл с текстом в кодировке latin1. Получишь 30 мб tar.

Что-то я сомневаюсь что tar такое сделает. Пруфлинк в студию.

вангую, что у него русские буквы превратились в HTML сущности utf-8, или в %D1%84. Если такое пожать, то и получится примерно вдвое больше оригинального utf-8.

emulek
()

нет, это неинтересно, ты мне лучше скажи, какого хрена однострочник на джаве отъедает у меня половину ОЗУ?

darkenshvein ★★★★★
()
Ответ на: комментарий от wxw

вопрос на засыпку - зачем нужен tar сейчас

для архивации файлов. Что-бы сделать из Over9000 файлов один. Один файл быстрее и проще переслать и/или зашифровать и/или ограничить доступ и/или задать какой-то атрибут(например для бекапа необходим атрибут «время бекапа», как этот атрибут повесить на Over9000 файлов?) и/или для любого другого действия, которое проще делается для одного файла (ну вот ещё пример: порежь мне Over9000 файлов на равные куски по X байт. А tar это делает искароппки).

emulek
()
Ответ на: комментарий от TEX

расскажи чем принципиально отличается tar от zip

тем, что твой zip — маздайный комбайн, нужный только для совместимости с DOS-подобными OS. Также, как и mkfs.msdos.

emulek
()
Ответ на: комментарий от TEX

не 16384 - а именно 10240 ?

тебе ж рассказали: для совместимости с древними ленточными накопителями. Лучше расскажи, на кой ляд этот дефолт менять сегодня? Быстрее и меньше всё равно не будет.

emulek
()
Ответ на: комментарий от TEX

3. Промежуток в 10Кб это дохрена. У спектрума всё ПЗУ помещалось в 16Кб

эти ленточные накопители были на несколько порядков больше(во всех смыслах) и быстрее магнитофона «электроника». Для них 10Кб это было «с гулькин нос», как по времени, так и по размеру.

emulek
()
Ответ на: комментарий от chg

минимальный tar должен занимать 512 байт на заголовок, тело с выравниванием по 512, то есть 123 это еще 512 и два блока-заполнителя в конце, еще 1024. итого 2 кб.

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

emulek
()
Ответ на: комментарий от TEX

То есть плотность ленты занимала 40Кб / 5*60 = 40960*8 / 300 = ~ 136 бит на секунду записи.

дык магнитофон предназначен для музыки ваще-то. Хранить на нём данные, это забивать гвозди микроскопом.

emulek
()
Ответ на: комментарий от TEX

но у меня ровно обратный вопрос, почему не сделать меньше ?

потому-что НЕ НУЖНО. Эти нули всё равно места не занимают.

emulek
()
Ответ на: комментарий от chg

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

ты можешь ведь и многотомный tar сделать. Если ты желаешь искать файл по имени, то отсортируй файлы по имени, и засунь в многотомный tar. Дальше сам догадаешься? В отличие от всяких говнозипов, таким образом, ты можешь сделать быстрый поиск не только по имени, а например по md5. Или по времени вставки.

Кстати, а твой zip умеет хранить Over9000 версий одного файла? Ну вот...

emulek
()
Ответ на: комментарий от darkenshvein

потому-что говнокод ненужный. Вот ТС «не нужно» тарит, а ты «не нужно» запускаешь. А эффект одинаковый.

emulek
()
Ответ на: комментарий от darkenshvein

Потому что это java не ? Настройки jvm одно, реальность потребности кода это другое.

Я в принципе тоже в одну строку написать xz -9 какой-либо файл - и оп почти гига ОЗУ нет.

TEX ★★★
() автор топика
Ответ на: комментарий от baka-kun

Так делает только GNU tar по историческим причинам.

А исторические причины с чем связаны ? Любопытно же

TEX ★★★
() автор топика
Ответ на: комментарий от redgremlin

Он дан давным давно - «historical reasons».

У исторических причин - должны быть корни. Неужели не любопытно почему так сложилось ?

Потому что тогда на ленту влезать меньше будет из-за вышерасписанных служебных промежутков.

Странное у вас рассуждение, мне почему то кажется что объем ленты,без сжатия естественно, не зависит от того 10Кб нулей на неё записывать или 1Кб. Если лента заявлена 90Мб, то на неё и влазит 90 Мб не ?

TEX ★★★
() автор топика
Ответ на: комментарий от Kosyak

Альтернативы?

А их очень мало, и это явно не повод гордиться сложившейся ситуацией.

Ну, там, с поддержкой симлинков и прав доступа.

Ну вот говорят есть такой dar и чего ? Неужто такая сложность сделать архив с указанной поддержкой. Да легко. Только нафиг никому не нужно. Потому что есть tar. Мать его за ногу

TEX ★★★
() автор топика
Ответ на: комментарий от TEX

Что ты прицепился к этим нулям? Ну не предназначен тар для записи однобайтных файлов. При записи же 10 гигового архива на ленту никому не интересно наличие в конце десятка килобайт нулей. А теперь предположим, что надо записать 10Г, а в служебную зону влезло бы 0.5К, т.е. размер записи+служебная область при 20 блоках 10.5К, таких записей 1М общей емкостью 10.5Г, потери 0.5Г. А при 2х блоках размер одного атома 1.5К, а надо их 10М, общая емкость 15Г, потери 5Г. Компрене ву, мон ами?

redgremlin ★★★★★
()
Ответ на: комментарий от emulek

Весь тред не читал, но уверен, что выше приводили форматы, как свободные, так и проприетарные, делающие всё то же, что и tar, только лучше (индекс, кодировки, точность временных меток, контроль целостности файлов, шифрование, многотомность, информация для восстановления...)

wxw ★★★★★
()
Ответ на: комментарий от redgremlin

Что ты прицепился к этим нулям?

Прекрасно ... А вам какое дело простите ? Можно поинтересоваться чего вы прицепились к моему любопытству по поводу нулей ?

Ну не предназначен тар для записи однобайтных файлов.

Это не объяснение. Это мантра. И да, я не ставил собой целью записывать туда однобайтные файлы, я с этой темой столкнулся когда бэкапилка начала выдавать 10Кб tar-ы вообще без файлов. Причем в ряде случаев tar обнаруживает что архив пуст и уничтожает его за собой, а в ряде случаев оставляет. Еще буду отлавливать ситуацию эту.

TEX ★★★
() автор топика
Ответ на: комментарий от redgremlin

А теперь предположим, что надо записать 10Г, а в служебную зону влезло бы 0.5К, т.е. размер записи+служебная область при 20 блоках 10.5К, таких записей 1М общей емкостью 10.5Г, потери 0.5Г

А теперь предположите что на ленту записывается не .tar а .tgz/.tar.gz - сжатие сводит на нет все эти свистопляски с блоками внутри tar. И дает нам бинарный кусок неизвестной длины

И что в итоге ? Либо записывать .tgz на ленту категорически не рекомендуется, либо вы зачем то приравниваете блоки на ленте к блокам внутри tar. На ленту писался не только tar как бы...

TEX ★★★
() автор топика
Ответ на: комментарий от wxw

Весь тред не читал, но уверен, что выше приводили форматы, как свободные, так и проприетарные, делающие всё то же, что и tar, только лучше (индекс, кодировки, точность временных меток, контроль целостности файлов, шифрование, многотомность, информация для восстановления...)

расскажи пожалуйста как реализовать

1. быстрое добавление и версионность

2. внутренний индекс.

Вот как расскажешь, так я и напишу аналог tar'а. Это единственное, что меня останавливает.

На самом деле, индекс не нужен, потому-что если нужен индекс, то не нужна затарка. Самый удобный и быстрый индекс и так есть в виде ext4 каталога.

emulek
()
Ответ на: комментарий от TEX

Причем в ряде случаев tar обнаруживает что архив пуст и уничтожает его за собой, а в ряде случаев оставляет. Еще буду отлавливать ситуацию эту.

там не уничтожение, а «робкий отказ от создания пустого архива». Это кстати не очень приятная фича. Я когда бекап делаю, туда первым делом пихаю список файлов, которые туда буду пихать. Это упрощает код. «Робкий отказ» это тоже ошибка с кодом 2. А я привык ВСЕ ошибки обрабатывать.

emulek
()
Ответ на: комментарий от TEX

А теперь предположите что на ленту

задолбал ты со своей лентой.

Либо записывать .tgz на ленту категорически не рекомендуется

this. Можешь ведь записывать не tar.gz, а gz.tar (сначала gz'ипишь, потом тариш)

emulek
()
Ответ на: комментарий от TEX

А исторические причины с чем связаны ?

Тебе уже не один раз сказали: с тем, что на разных UNIX такими блоками обычно писали архивы на ленты.

мне почему то кажется что объем ленты,без сжатия естественно, не зависит…

Тебе кажется.

Если говорить о временах повсеместного 'tar -b 20', когда размер блока де-факто стал 10К, самые распространенные девятидорожечные катушечные накопители имели плотность 800 или 1600 bpi. Защитный интервал между блоками был 15 миллиметров, то есть около килобайта. Это то расстояние, за которое лентопротяг гарантированно успевал остановиться со скорости более пяти метров в секунду, не порвав ленту.

Стандартная лента имела длину 730 метров, примерно 88–90 тысяч блоков по 512b без учета защитных интервалов. Писали блоками 10К, влезало примерно 40М данных.

Если какой-нибудь идиот будет писать блоками по 512b, на ленту поместится всего 14М данных.

предположите что на ленту записывается не .tar а .tgz/.tar.gz

Предложи быстрый алгоритм поиска файла на такой ленте без чтения всего архива.

Файл tar — это образ ленты, как быстро найти в нем нужный файл при наличии всего трех команд: rewind, read, seek — задача решенная. Как это сделать с tgz без чтения всего архива?

baka-kun ★★★★★
()
Последнее исправление: baka-kun (всего исправлений: 3)
Ответ на: комментарий от baka-kun

Вот это уже интереснее и обстоятельне. Спасибо

Предложи быстрый алгоритм поиска файла на такой ленте без чтения всего архива.

Зачем - ответ очевиден, ибо устройства с последовательным доступом таки имеют последовательный доступ.

Файл tar — это образ ленты, как быстро найти в нем нужный файл при наличии всего трех команд

А ...понял, то есть tar адаптировал свой формат что бы путем подсчета собственных блоков более точно управлять лентой для seek внутри tar файла. Самой же ленте по идее глубоко пофигу на эти блоки.

TEX ★★★
() автор топика
Ответ на: комментарий от emulek

На самом деле, индекс не нужен, потому-что если нужен индекс, то не нужна затарка. Самый удобный и быстрый индекс и так есть в виде ext4 каталога.

Ты можешь взять этот индекс для части файлов, выложить его и файлы на веб-сервер, что бы твой друг батя мог скачать его на другой комп и восстановить выложенные файлы естественно со всеми атрибутами ?

Вот поэтому ты и не пишешь аналог tar. Ибо не можешь.

TEX ★★★
() автор топика
Ответ на: комментарий от emulek

заголовок совместить нельзя, а два заполненных нулями блока в хвосте не обязательны.

chg ★★★★★
()
Ответ на: комментарий от TEX

Зачем

Затем, что tgz необходимо читать весь, а tar можно проматывать. Одно будет 20 см/с, другое — 5 м/с.

то есть tar адаптировал свой формат

Формат tar — это образ ленты. В буквальном смысле. Каждая команда чтения с накопителя вернет следующие 'block size' байт. Минимальный размер данных, которые можно прочитать с ленты — один блок, то есть расстояние от одного межблочного интервала до следующего. Даже если тебе нужен один байт, лента будет перемотана до следующего промежутка.

Самой же ленте по идее глубоко пофигу на эти блоки.

Самой ленте может и пофиг, но привод умеет только вернуться в начало ленты , читать n блоков вперед и перемотать n блоков вперед. И нужно успеть остановиться до блока n+1. При перемотке считать блоки можно только по паузам между ними (или по сервометкам в современных системах), данные на такой скорости недоступны.

baka-kun ★★★★★
()
Ответ на: комментарий от emulek

в таре нет индексации. Не важно, что и как ты туда засунешь, все равно внутри файла придется искать линейно по заголовкам с самого начала, так как в заголовке каждого блока содержится только размер данных, а смещения неизвестны. там нет даже сигнатуры. так что, нет, сам не догадаюсь. подсказывай ;)

что такое многотомный тар?

что такое версии одного файла? файлы с одинаковыми именами? да, в зип можно закатать файлы с одинаковыми именами. Принцип тот же, но какой в этом смысл?

chg ★★★★★
()
Ответ на: комментарий от TEX

Самой же ленте по идее глубоко пофигу на эти блоки.

ленте может и пофиг, а вот всякие блочные устройства типа флоппи, HDD и SSD имеют как раз блок(который сектор) в 512 байт.

emulek
()
Ответ на: комментарий от TEX

Ты можешь взять этот индекс для части файлов, выложить его и файлы на веб-сервер, что бы твой друг батя мог скачать его на другой комп и восстановить выложенные файлы естественно со всеми атрибутами ?

нет. Потому-что я добавлю файлов, а друг уже скачал старый индекс.

Вот поэтому ты и не пишешь аналог tar. Ибо не можешь.

ещё я не могу делить на ноль.

У так есть свои особенности, но это не баги, и не фичи. Это особенности, которые приводят к багами и фичам.

emulek
()
Ответ на: комментарий от emulek

нет. Потому-что я добавлю файлов, а друг уже скачал старый индекс.

При помощи архиватора описанная задача решается на ура. А вот при помощи индекса ext4 не решается. На кой ты его приплел неизвестно

TEX ★★★
() автор топика
Ответ на: комментарий от TEX

При помощи архиватора описанная задача решается на ура. А вот при помощи индекса ext4 не решается. На кой ты его приплел неизвестно

На кой ляд ты приплёл суда какой-то левый веб сервер с каким-то дурацким индексом из твоего архиватора? Вот любуйся на индекс: http://mirror.yandex.ru/ Чем тебя это не устраивает, и зачем нужны костыли с архиваторами?

Сдаётся мне, что ты вообще смутно понимаешь, зачем нужен архиватор. И это печально.

И выше я уже обрисовал, зачем нужен архиватор в принципе: Почему минимальный tar aрхив занимает нехилых 10Кб ? (комментарий)

Ты наверное знаешь ещё какие-то применения? Делись, жду с нетерпением. А то у нас наметилось некоторое непонимание.

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.