Чтобы не читать весь файл -- эта информация должна находится где-то в начале файла
Не обязательно. Если заголовок будет у каждого «файла» с известным размером, то получится что-то вроде linked list, что будет лишь слегка похуже единого заголовка. Да, можно еще в конец файла постфактум записывать каталог.
Вот именно. (: Если писать в конец, потоковость теряется только для извлечения списка, а не для упаковки/распаковки.
Если список класть отдельным элементом, то не придётся.
Кроме списка, надо еще делать прерывания в компрессии, чтобы можно было разжимать не с начала. Иначе нафиг этот список нужен-то, если чтобы достать один файл все равно весь архив надо распаковать.
Если список класть отдельным элементом, то не придётся.
Кроме списка, надо еще делать прерывания в компрессии, чтобы можно было разжимать не с начала. Иначе нафиг этот список нужен-то, если чтобы достать один файл все равно весь архив надо распаковать.
Во-во. А расставлять эти прерывания в компрессии кто будет? Правильно, архиватор. Т.е. архиватор должен уметь управлять внутренней работой компрессора. И опять 2-в-1.
Если список класть отдельным элементом, то не придётся.
Кроме списка, надо еще делать прерывания в компрессии, чтобы можно было разжимать не с начала. Иначе нафиг этот список нужен-то, если чтобы достать один файл все равно весь архив надо распаковать.
Естественно. Но эти прерывания тоже не мешают потоковости, только меняют её направление: не «архиватор -> компрессор», а «компрессор -> архиватор»
Если список класть отдельным элементом, то не придётся.
Кроме списка, надо еще делать прерывания в компрессии, чтобы можно было разжимать не с начала. Иначе нафиг этот список нужен-то, если чтобы достать один файл все равно весь архив надо распаковать.
Во-во. А расставлять эти прерывания в компрессии кто будет? Правильно, архиватор. Т.е. архиватор должен уметь управлять внутренней работой компрессора. И опять 2-в-1.
Зачем управлять-то? Он может отдать компрессору _каждый_ файл и получить от него обратно, а потом уж сам расставить метки.
не мешают потоковости, только меняют её направление: не «архиватор -> компрессор», а «компрессор -> архиватор»
Тогда это должен быть очень умный компрессор, почти архиватор, т.е. почти 2-in-1. Этот компрессор должен уметь обходить дерево каталогов, выковыривать метаинформацию о файлах и в каком-то, очень похожем на потоковый архив a la tar, виде гнать поток в архиватор. А что остается на долю собственно архиватора?
Да, еще компрессор должен уметь все способы обработки спец. файлов, которые умеют современные компрессоры+архиваторы. Как пример: FIFO. Что с ним делать: читать и компрессить из него поток, как это делают потоковые компрессоры, или передавать метаинфу, как это делают архиваторы, вроде tar?
Собственно, если tar czf archive files — аналог tar cf - files | gzip >archive, то я говорю о чём-то вроде tar cf archive <(gzip -c file1) <(gzip -c file2) …
Собственно, если tar czf archive files — аналог tar cf - files | gzip >archive, то я говорю о чём-то вроде tar cf archive <(gzip -c file1) <(gzip -c file2) …
Да, вот еще одно нарушение потоковости: никогда заранее не известно, какой размер будет занят сжатым файлом в архиве, пока его не сожмут полностью, т.е. нельзя поточно создать «заголовок» перед файлом в архиве, только записать метаинфу после него. Т.е. весь архив вообще будет «задом наперед». :)
Вообще, идея такого "поточного 2-в-1" имеет право на жизнь, и, возможно, найдёт аудиторию. Но я предпочту tar.
А я по ситуации. Если нужно сжать цельную работу из сотен файлов, то tar. А если подборку статей или книг, которые удобнее выдёргивать по одной, то нет.
Теоретически для второго варианта подошла бы, и даже лучше, фс со внутренним сжатием. Но на практике фс нужно сначала разметить под конкретный размер, а уже потом нагрузить файлами.
идея такого "поточного 2-в-1" имеет право на жизнь, и, возможно, найдёт аудиторию. Но я предпочту tar.
Собственно, вот прямо сейчас родилась идея. Не совсем KISS, но почти. Некий «компрессор», который принимает на входе поток tar, умеет частично обрабатывать заголовки файлов tar, сжимать содержимое и выдавать поток архива «задом наперед», о котором я писал выше. При распаковке умеет находить нужные файлы (если пользователю нужны не все), разжимать и выплевывать на выход поток tar.
:)
Единственный минус — привязка к формату потока.
Да, вот еще одно нарушение потоковости: никогда заранее не известно, какой размер будет занят сжатым файлом в архиве, пока его не сожмут полностью, т.е. нельзя поточно создать «заголовок» перед файлом в архиве, только записать метаинфу после него. Т.е. весь архив вообще будет «задом наперед».
Метаинформацию можно искать не по адресу, а по сигнатуре. И она же может служить меткой начала файла.
Добавлю для ясности: я не предлагаю выбросить tar и использовать архиваторы «два в одном» вроде 7z. Я это к тому, что по-хорошему вместо tar-а давно пора написать новый «потоковый» архиватор, учитывающий современные реалии.
не вижу никакого смысла. новый сжиматель лучше чем LZMA2 (xz) я сейчас делаю. но вот лучше тара... как на лоре говорят - "не нужен".
Чтобы не читать весь файл -- эта информация должна находится где-то в начале файла, а это убивает потоковость.
Если хочется потоковости, то придётся попрощаться с тем, чтобы список файлов был доступен до прочтения всего архива -- изменить заголовок уже не получится.
Не обязательно. Если заголовок будет у каждого «файла» с известным размером, то получится что-то вроде linked list, что будет лишь слегка похуже единого заголовка. Да, можно еще в конец файла постфактум записывать каталог.
я думаю в каждом блоке хранить содержимое этого блока.
Да, вот еще одно нарушение потоковости: никогда заранее не известно, какой размер будет занят сжатым файлом в архиве, пока его не сожмут полностью, т.е. нельзя поточно создать «заголовок» перед файлом в архиве, только записать метаинфу после него. Т.е. весь архив вообще будет «задом наперед». :)
если сжимать блоками, то вполне можно перед блоком записывать всю информацию.
если сжимать блоками, то вполне можно перед блоком записывать всю информацию.
Какую всю? Всю метаинформацию о файле (имя, mtime, ctime, owner, group, permissions, ...) дублировать в каждом блоке? А зачем? Во-вторых, зачем блоки в файле? Это ведь не файловая система, где жертвуют эффективностью использования пространства в пользу скорости. Тут как раз важнее пространство, о скорости позаботится ФС.
(inurl) писал(а):Ленточная библиотека имеет значительные преимущества перед дисковым массивом по стоимости и энергопотреблению при больших объёмах хранимых данных. Например, согласно расчётам издания Clipper Notes, для поддержания в постоянном доступе архива размером 6,6 петабайт в течение 5 лет, стоимость дисковой системы (RAID-массивов, контроллеров, разветвителей, дисков, питания, охлаждения и пр.) составит 14,7 млн долларов (в том числе стоимость электроэнергии — 550 тыс. долларов), в то время как стоимость ленточной библиотеки — менее 700 тыс. долларов (в том числе стоимость электроэнергии — 304 доллара).
...а они есть.
p.s. дома нет стримера, но в 80-ых активно пользовался аудиокассетами (;
Какую всю? Всю метаинформацию о файле (имя, mtime, ctime, owner, group, permissions, ...) дублировать в каждом блоке? А зачем? Во-вторых, зачем блоки в файле? Это ведь не файловая система, где жертвуют эффективностью использования пространства в пользу скорости. Тут как раз важнее пространство, о скорости позаботится ФС.
Нет, не обязательно. Можно, например, в начале блока ставить размер блока (который может быть меньше для хвоста файла), бит, показывающий, является ли блок первым для нового файла, и заголовок, если является. Размер сжатого потока в заголовок не входит. Просто распаковываются все блоки до тех пор, пока не встретится очередной "первый".
У меня уже была когда-то такая идея. Но она тоже разбивается об необходимость создания 2-в-1.
Добавлю для ясности: я не предлагаю выбросить tar и использовать архиваторы «два в одном» вроде 7z. Я это к тому, что по-хорошему вместо tar-а давно пора написать новый «потоковый» архиватор, учитывающий современные реалии.
не вижу никакого смысла. новый сжиматель лучше чем LZMA2 (xz) я сейчас делаю. но вот лучше тара... как на лоре говорят - "не нужен".
Я выше написал, зачем он нужен. Есть другое решение (кроме архиваторов «два а одном»)? Подпорку с временными файлами не предлагать.
Какую всю? Всю метаинформацию о файле (имя, mtime, ctime, owner, group, permissions, ...) дублировать в каждом блоке? А зачем? Во-вторых, зачем блоки в файле? Это ведь не файловая система, где жертвуют эффективностью использования пространства в пользу скорости. Тут как раз важнее пространство, о скорости позаботится ФС.
почему "дублировать"? в начале архива хранится лишь информация о типе архива, а в каждом блоке лежит информация о файлах (имя, права, штампы, прочее). Это такая файловая система. Только я жертвую скорость в пользу места. для того, что-бы прочитать имена и прочее, мне достаточно прочитать заголовки блоков.
Нет, не обязательно. Можно, например, в начале блока ставить размер блока (который может быть меньше для хвоста файла), бит, показывающий, является ли блок первым для нового файла, и заголовок, если является. Размер сжатого потока в заголовок не входит. Просто распаковываются все блоки до тех пор, пока не встретится очередной "первый".
я просто пишу в заголовок блока все имена/права файлов. блок всегда содержит 1 файл, кроме случая, когда файл больше размера блока (тогда 1 файл сохраняется в нескольких блоках).
Есть другое решение (кроме архиваторов «два а одном»)? Подпорку с временными файлами не предлагать.
нет.
ЗЫЖ по моей схеме в одном блоке может находится любое число файлов. размер блока определяется алгоритмом BWT и равен примерно 10*N. Если памяти 100Мб, то размер блока == 10Мб.
(inurl) писал(а):Ленточная библиотека имеет значительные преимущества перед дисковым массивом по стоимости и энергопотреблению при больших объёмах хранимых данных. Например, согласно расчётам издания Clipper Notes, для поддержания в постоянном доступе архива размером 6,6 петабайт в течение 5 лет, стоимость дисковой системы (RAID-массивов, контроллеров, разветвителей, дисков, питания, охлаждения и пр.) составит 14,7 млн долларов (в том числе стоимость электроэнергии — 550 тыс. долларов), в то время как стоимость ленточной библиотеки — менее 700 тыс. долларов (в том числе стоимость электроэнергии — 304 доллара).
...а они есть.
p.s. дома нет стримера, но в 80-ых активно пользовался аудиокассетами (;
Исключения лишь подтверждают правила. (: Я понимаю, что штучные экземпляры есть.
