[Ruslan1 17]

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

С такими тормозами я не представляю чем дивайс еще может заниматься.

Ну так они не внавал миллионами лежат, а по дневным дирректориям, в каждой 1440 файликов. В момент копирования нового файла "в архив" тормозов сильных нет, всего-то 1237-й файл в известную дирректорию добавить.

Тормоза только после включения и ежесуточно, когда система проверяет все архивные фолдеры на предмет "а кто тут старее чем указанное в конфиге время жизни для этого типа файлов?" и удаляет старые. Вот это да, закат солнца вручную. (кстати, мой контейнер и этому горю поможет). Но это одна из задач многозадачки, так что не критично -остальное бегает в параллель.

 

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

Вот в Линуксе с его единой таблицей inode есть потенциальные грабли насчет количества файлов. Но там скрипты подтирают- принятый файл сразу после затягивания в базу данных добавляется в архив и удаляется. Как-то слетел скрипт - так inode на FTP была забита за неделю :)

[Ruslan1 17]

Понятно. Если это резервный архив, то почему не делать один файл на час или день? А на компе своей утилиткой выделять ежеминутные данные, когда это в исключительном случае потребуется. Зачем эта 100% идентичность? Тем более, все равно объединяете в один файл. Вам, конечно, виднее.

Еще и на количестве записей на диск сэкономите.

Я с Вами полностью согласен, так нужно делать, когда это возможно. Но сильно не хочется свою утилитку делать (не только из-за лени). А еще больше "попонтоваться" хочется: "ну что, конкуренты коллеги, у меня zip, а у вас?" :)

[mantech 53]

Вы, вероятно, не сталкивались с подобным, у меня сейчас ситуация следующая: за 100 дней накапливается почти полтора миллиона файлов, занимающие 4 гигабайта (если кластер 32к) на устройстве хранения, при этом собственно файлы имеют общий объем 24 мегабайта.

 

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

[Ruslan1 17]

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

Перепроверил: у ISO большой заголовок на диск, и он хранится в теле этого iso файла. Плюс минимальный размер сектора - 2 килобайта, и каждый файл в своем секторе. В результате стоимость входа 50 килобайт, плюс по 2 килобайта на файл.

В-общем, это как переход от одной операционки к другой, выигрыша по занимаемому месту нет никакого так как нужно хранить файловые таблицы и файлы квантуются сектором 2К.

 

Пока что zip видится лучшим контейнером. попробую накропать что-то за вечерок... CRC32 не нравится, да и промежуточный буфер(даже файл) нужен для хранения этих хвостовых central directory header, но нет в мире совершенства....

 

[Ruslan1 17]

В-общем, реализовал tar с дописыванием в архив новых файлов по нужде. Имею желание в будущем добавить gzip и получить tgz.

 

сам по себе zip - тупик, если нужно даже сжать много файлов. Как контейнер он лучше чем tar, а дальше сплошные минусы и по сложности подготовки(нужно много данных хранить даже просто для организации контейнера,) и в будущем сжатия большого не даст. А делать zip для контейнера и потом еще раз сжимать этот зип как один файл- это мазохизм, уж лучше стандартный путь, через тар. Ну и с таром дописывание- это норма, а не изврат как с зипом.

 

Кстати, с Таром тоже хватило эротики- описание только на первый взгляд понятное, пришлось и в исходники за деталями залезть, а они не самые простые. Первые(простые)- не годятся, так как формат поменяли по дороге, по этой же причине в интернете разброд и шатание, могу найти противоречащие друг другу описания.

Более того- разные программы дают разный файл, и по хедеру и по длине, например ТоталКомандер и 7-zip, но не отказываются раскодировать файлы друг друга- видна повышенная толерантность и пофигизм к содержимому неосновных полей хедера и финальному маркеру :) (7Zip- лучше, я не нашел отклонений от описания в полученном с его помощью файле).

 

следующий виток- gzip, но тут вроде есть готовое, хочу попробовать mini_gzip

[firew0rker 0]

Я применила для такой задачи (сбор и ежесуточное архивирование данных) х86-совместимый пром.компьютер под Linux.

Для задачи попроще (файл был один) на STM32F103 применила архивaтор XZ Embedded

[Alechek 0]

Для задачи попроще (файл был один) на STM32F103 применила архивaтор XZ Embedded

XZ Embedded is a relatively small decompressor for the .xz file format.

 

[firew0rker 0]

Так мне и надо было распаковать 1 файл на МК.

Если надо упаковать, есть библиотеки:

1. miniz

2. liblzf

[AlexandrY 3]

Если надо упаковать, есть библиотеки:

1. miniz

2. liblzf

 

Похоже ничего нового в этом мире нет.

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

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

[firew0rker 0]

Показать достаточно распространенный разархиватор на PC для указанных форматов. ;)

 

miniz пишет ZIP файлы.

 

При компиляции релиза liblzf получается (рас/у)паковщик в виде бинарника lzf которым элементарно просто пользоваться.

 

Может быть использовать не архиватор, а файловую систему со сжатием, например NTFS?

Исходники ntfs-3g бесплатны, открыты. А за деньги можно приобрести NTFS Embedded

Изменено 7 декабря, 2016 пользователем firew0rker

[AlexandrY 3]

miniz пишет ZIP файлы.

 

При компиляции релиза liblzf получается (рас/у)паковщик в виде бинарника lzf которым элементарно просто пользоваться.

 

Да можно много барахла найти по всяким свалкам исходников, никто не спорит.

Но во первых вы даже видимо не смотрели сколько памяти требует этот miniz, а во вторых видимо думает, что в STM32 есть такая же файловая система как в линуксе.

[firew0rker 0]

Да можно много барахла найти по всяким свалкам исходников, никто не спорит.

Но во первых вы даже видимо не смотрели сколько памяти требует этот miniz, а во вторых видимо думает, что в STM32 есть такая же файловая система как в линуксе.

 

Не только барахла, много ценного тоже нарыть можно.

На STM32 можно работать и с файловой системой как в Линуксе, и с самим Линуксом!

[Ruslan1 17]

Спасибо, но на линукс ради архиватора переходить не стану в данном устройстве.

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

Я поскреб по сусекам- наскреб у себя около полмегабайта РАМа, который смогу архиватору "во временное пользование" выделять, думаю это сильно расширит горизонты. Но вот нерезиновое ПЗУ экономить все равно нужно.

 

И, к слову, называль Линуксом uClinux - ну, у меня лично язык не поворачивается. Все ж таки MMU нужно, чтоб Линуксом назваться. И я с uClinux наигнался в его Блекфиновской инкарнации, и драйверы свои писал в него к моему железу тогдашнему, и оно даже работало. Как-то работало. Очень "как-то". И то был Блэкфин, а не свистелка STM32.

[jcxz 243]

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

Вопрос к ТС-у:

Как я понял Вы остановились на tar? И уже имплементировали его?

У меня сейчас в чём-то сходная задача: нужно в прошивку устройства добавить содержимое некоего HTTP-сервера. И я тоже искал контейнер, чтобы объединить все файлы в один файл, из которого уже можно находить нужные отдельные файлики внутри firmware. Вопрос о сжатии пока не стоит.

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

И я остановился на cpio. Вы его рассматривали? https://habrahabr.ru/post/130092/

Утилитка для него есть и под винду.

[Ruslan1 17]

Как я понял Вы остановились на tar? И уже имплементировали его?

...

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

И я остановился на cpio. Вы его рассматривали?

Да, сейчас я использую tar.

Нет, я не рассматривал cpio, так как не думал о нем как о "стандартном" упаковщике.

Очень может быть, что cpio лучше. По оверхеду он явно лучше, но может есть какие-то хитрости.