Сайт | Скачать | Видео | Wiki

Автор Тема: PRA + pfs-utils  (Прочитано 11073 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
PRA + pfs-utils
« : 18 Август 2013, 09:54:46 »
В свете использования pfs-utils в PRA хочу напомнить пожелания, которые уже высказывал:
1. Переделать /etc/packages на /var/lib/pacman/local . Там только %Files% в начало дописать. Конвертор есть в pkg2pfs. Это даст возможность установленный pfs сносить packman-oм. Он же разрулит зависимости.
2. Не заморачиваться зависимостями методом поиска либ (ldd). Делать %DEPENDS% в /var/lib/pacman/local/*/desc руками. В конце pfsload проверить и доустановить зависимости pacman-ом. Вообще я за то, чтобы в pfs модуле уже все было внутри. Подключил-запустилось. Т.е. не должно быть либа.pfs. В идеале все требующее сборки делать pacman-ом (т.е. все переделать на свою репу). Задачи pfs-util - склейка, подключения, установка
3. Переделать некоторые сообщения , требующие нажвтия OK на всплывающие (например ntf). Особенно напрягает "Модуль подключен"
4. Подключение в память мы перемудрили. Достаточно скопировать на имеющийся tmpfs и оттуда подключить. Надо ли создавать доп. tmpfs
5.  checkramfree требует доработки (после того как определимся с initrd)
6. mksquashfs "${pfsdir}" "${userout}" -b 256K -comp xz -Xbcj x86 - чем обусловлена боязнь увеличения сжатия. Юзаю. Проблем не встречал. Кое где делают -b 512K. Кто глубоко в теме компрессии и может пояснить 256\512?

Zay, можно на Вас рассчитывать в этой теме?

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:PRA + pfs-utils
« Ответ #1 : 18 Август 2013, 19:35:10 »
1. лучше выбирать путь без привязки к дистрибутивам, будет более универсальным, но часть дистрозависимых фишек, конечно, не будет.
5. возможно другое, но по названию ассоциируется с нашим скриптом addmemory. Посмотрите, может пригодится.
6. чем больше блок, тем выше сжатие, но памяти кушает больше.
Томас проводил эксперименты и остановился на 512 как на среднем варианте. Я с ним согласен, поэтому мы используем тоже 512.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #2 : 18 Август 2013, 19:59:27 »
1. В каком формате будет /etc/packages - в своем или в арчовом - для magos без разницы. Работать будут так же
Сейчас ни с чем не совместимо - будет с арчем. Насчет совместимости с rpm - мало знаком с форматом
Общую идею поддерживаю - уменьшать универсальность в сторону арч - не надо
6. Можно подробнее про "выше сжатие, но памяти кушает больше"

Оффлайн neobht

  • Ветеран
  • *****
  • Сообщений: 1031
  • Репутация: +15/-0
Re:PRA + pfs-utils
« Ответ #3 : 18 Август 2013, 20:23:31 »
6. squashfs - это блочное сжатие, чем выше размер блока тем алгоритм лучше упаковывает избыточность данных ввиду того, что большая длинна цепочек повтора на большем объеме данных (тут не хотелось бы в теорию впадать, есть разные алгоритмы). А поскольку при расжатии необходимо выстраивать обратный процесс генерации данных, то больший блок кушает больше памяти в ОЗУ. При современных мерках это почти не заметно, но если вы стремитесь к минимизации ресурсов, то это может быть уже ощутимо. У вас дистр по размеру близок к slax, поэтому думаю стоит не боясь выбирать 512. У нас возможно даже стоило бы выбрать 1024.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #4 : 18 Август 2013, 22:33:05 »
В скриптах porteus вроде, 256 стоит
PRA жал -b 256k
Пробовал 512 - ощутимого уменьшения не заметил. Может файлы были плохо сжимающиеся. Надо будет еще попробовать
Ну и видимо, чем больше сжатие - тем больше нагрузка на проц

Оффлайн Zay

  • Почетный участник
  • Ветеран
  • *
  • Сообщений: 1536
  • Репутация: +25/-0
Re:PRA + pfs-utils
« Ответ #5 : 19 Август 2013, 00:00:21 »
Сразу скажу, с packman-oм я пока что не разбирался, поэтому буду задавать вопросы для общего понимания.

Переделать /etc/packages на /var/lib/pacman/local . Там только %Files% в начало дописать. Конвертор есть в pkg2pfs. Это даст возможность установленный pfs сносить packman-oм. Он же разрулит зависимости.
Сомнительное решение, как мне кажется.
Разделение на /mount и /install в pacman'е есть? Если нет - то теряем одно из преимуществ PFS, универсальность использования.
Теряется совместимость с уже существующими модулями (а их не так уж и мало).
Минусы значительные, а плюсы какие? Если я что-то не до конца понял - поправьте.

Вообще мне кажется что лучше использовать pacman исключительно для закачки пакетов из репозитория и разрешения зависимостей.
Для этого можно было бы написать обёртку к pacman-у, которая:
 1. Перед запуском создаёт файлы в "/var/lib/pacman/local" анализируя "/etc/packages".
 2. Запускает pacman и заставляет его скачать все нужные пакеты.
 3. Конвертирует каждый пакет в формат PFS, затем объединяет полученные пакеты в один файл (если требуется).
Таким образом на выходе получится один PFS-файл с нужными пакетами и всеми его зависимостями.

Не заморачиваться зависимостями методом поиска либ (ldd).
Этот функционал уже практически реализован, зачем ломать?
Единственно что я планирую сделать - это перенести соответствующие функции из mkpfs в отдельный скрипт.

Вообще я за то, чтобы в pfs модуле уже все было внутри. Подключил-запустилось. Т.е. не должно быть либа.pfs.
В модуле - согласен. Но пакеты должны быть отдельными, иначе теряется серьёзное преимущество PFS (пакет != модуль).

Переделать некоторые сообщения , требующие нажвтия OK на всплывающие (например ntf). Особенно напрягает "Модуль подключен"
Эти сообщения с таймером, если не нажимать кнопку - они через несколько секунд сами закрываются.
Но подумать в этом направлении можно.

Подключение в память мы перемудрили. Достаточно скопировать на имеющийся tmpfs и оттуда подключить. Надо ли создавать доп. tmpfs
Существующее решение продумано и работает достаточно надёжно. К тому же оно логично. Не вижу особого смысла переделывать...

checkramfree требует доработки (после того как определимся с initrd)
Если возможно улучшить - я только за. Но сам не разбираюсь в вопросе достаточно.

mksquashfs "${pfsdir}" "${userout}" -b 256K -comp xz -Xbcj x86 - чем обусловлена боязнь увеличения сжатия. Юзаю. Проблем не встречал. Кое где делают -b 512K. Кто глубоко в теме компрессии и может пояснить 256\512?
Принял к сведению. Возможно реализую что-то подобное, но скорее всего опционально. Где бы посмотреть возможные варианты настроек компрессии?

Zay, можно на Вас рассчитывать в этой теме?
Я планирую продолжать доработку и поддержку PFS-utils, возможность использования в PRA конечно тоже постараюсь учесть.
Свободного времени у меня сейчас, к сожалению, мало, но думаю осенью будет лучше.

Оффлайн betcher

  • Ветеран
  • *****
  • Сообщений: 3019
  • Репутация: +35/-0
    • MagOS linux
Re:PRA + pfs-utils
« Ответ #6 : 19 Август 2013, 08:51:02 »
A что это - checkramfree? Антон предположил, что это  вроде нашего addmemory. Скрипт увеличивает на лету размер tmpfs за счет подключения swap файлов. Столкнулись с проблемой, что в "чистом" режиме (когда изменения пишутся в tmpfs) случаются ситуации когда система виснет от того, что в корне исчерпано место. Например при распаковке больших архивов.  Решили таким скриптом.
Вот здесь обсуждение было http://magos-linux.ru/index.php?option=com_agora&task=topic&id=543&p=1&Itemid=55#p7382
А тут сам скрипт https://github.com/magos-linux/magos-linux/blob/master/make_MagOS/files/patches/rootfs/rootfs/usr/lib/magos/scripts/addmemory
« Последнее редактирование: 19 Август 2013, 08:53:31 от betcher »

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #7 : 19 Август 2013, 10:34:34 »
A что это - checkramfree?
http://forum.puppyrus.org/index.php/topic,12819.msg70812.html#msg70812
Проверка наличия памяти перед подключением модуля с копированием в память
Стандартные утилиты врут. Подставили костыль
Антон предположил, что это  вроде нашего addmemory. Скрипт увеличивает на лету размер tmpfs за счет подключения swap файлов.
У нас был замысел держать весь дистр в памяти. Что даст быстроты, экономию батареи , винта, флэшей
Если юзать swap - тогда "за что боролись". Подключить модуль с носителя
Тем более, что запущенная прога - и так в памяти.
Честно говоря, у меня до сих пор нет ясности с подключением в память. Только "от обратного" : памяти на виндомашине по меркам пупи - вагон. Хоть для чего-то это использовать
Столкнулись с проблемой, что в "чистом" режиме (когда изменения пишутся в tmpfs) случаются ситуации когда система виснет от того, что в корне исчерпано место.
У нас в трее висит freememapplet

Оффлайн betcher

  • Ветеран
  • *****
  • Сообщений: 3019
  • Репутация: +35/-0
    • MagOS linux
Re:PRA + pfs-utils
« Ответ #8 : 19 Август 2013, 10:58:14 »
Использование addmemory - крайний случай. Например если магос загружен в чистом режиме на машине менее чем c 2 гигами, то даже распаковка архива со сборкой  может привести к переполнению tmpfs.
Я этим скриптом практически не пользуюсь, разве что при работе с флешки. При стационарной установке создаю swap раздел и добавляю к параметрам ядра findswap и ramsize=200%, тогда при 2 гигах оперативы и нескольких гигах swap размер tmpfs будет 4 гига (вдвое больше RAM). При этом реально своп используется редко, в основном при задачах активно пишущих в /tmp.  А если нехватит и 4 гигов, тогда уже addmemory.
Апплет, который следит за памятью это идея хорошая,  мы собирались демона писать, чтоб ругался когда память заканчивается и предлагал использовать addmemory.
« Последнее редактирование: 19 Август 2013, 11:09:11 от betcher »

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #9 : 19 Август 2013, 11:40:34 »
Апплет, который следит за памятью это идея хорошая,  мы собирались демона писать, чтоб ругался когда память заканчивается и предлагал использовать addmemory.
Аналогичное реализовано (но жестко минималистично) в моих коньках Последняя версия в репе sfs-get в PRA

Под Вас наиболее подойдет http://forum.puppyrus.org/index.php/topic,13900.msg76616.html#msg76616
... :D Чувствую все закончится появлением в MOS jwm   ;)

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #10 : 19 Август 2013, 12:00:12 »
Сразу скажу, с packman-oм я пока что не разбирался
Обычный ПМ
Переделать /etc/packages на /var/lib/pacman/local . Сомнительное решение
Например: прога прикручена pfs-ом. Надо обновить или удалить пакет. Без var/lib/pacman/local pacman нас не поймет
Получается лучше в модулях-софта.pfs лучше не иметь var/lib/pacman/local. Тогда пакман напугает сообщением что файлы уже есть и с ключом --force все правильно сделает
Особенное зло - выкинуть dev составляющую и оставить var/lib/pacman/local - пакман будет думать что пакет есть , а он неполный = проблемы при компиляции

Получается лучше не заморачиваться с var/lib/pacman в pfs. Исключение - забыли положить пакет в базу. Для этого написал pkg2pfs (надо дорабатывать).
лучше использовать pacman исключительно для закачки пакетов из репозитория и разрешения зависимостей.
Он больше ничего и не умеет
Написал еще скрипт pacman2pfs - он создает монолитный (без деления на пакеты) модуль.pfs
Поскольку бьемся за размер - в таком модуле не вредно порезать лишнее и тогда удалить var/lib/pacman

Таким образом получаем 3 вида модулей.pfs в PRA:
1. pacman. Собраны pacman. pfs-mono. Есть var/lib/pacman и devx.pfs
2. pfs. Собраны как угодно (руки, pacman2pfs). pfs-mono или мета. Нет var/lib/pacman и devx.pfs
3. Гибридный. pfs-meta из 1 и 2
Главное поддерживать "чистоту" 1 и 2 в плане var/lib/pacman и devx

Но пакеты должны быть отдельными, иначе теряется серьёзное преимущество PFS (пакет != модуль).
В PRA пакеты - формата pkg. Конвертировать в pfs каждый не вижу смысла. Исключение - pkg2pfs - забыли положить в базу. Пересобирать поздно или лень

checkramfree в PRA не работает, т.к. написан под наш старый инитрд.
Где бы посмотреть возможные варианты настроек компрессии squashfs?
mksquashfs --help
Я планирую продолжать доработку и поддержку PFS-utils, возможность использования в PRA конечно тоже постараюсь учесть.
Спасибо. Рассчитывал на Вас

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #11 : 19 Август 2013, 18:08:04 »
Поэкспериментировал с ключами mksquashfs:
unsquashfs 10-BASE от PRA = 116мб файлов
Жму:
 -comp xz -Xbcj x86 = 33мб
-b 256K -comp xz -Xbcj x86 = 32мб
-b 512K -comp xz -Xbcj x86 = 31мб

Оффлайн Zay

  • Почетный участник
  • Ветеран
  • *
  • Сообщений: 1536
  • Репутация: +25/-0
Re:PRA + pfs-utils
« Ответ #12 : 19 Август 2013, 23:26:29 »
Например: прога прикручена pfs-ом. Надо обновить или удалить пакет. Без var/lib/pacman/local pacman нас не поймет
...
Получается лучше не заморачиваться с var/lib/pacman в pfs.
...
В PRA пакеты - формата pkg. Конвертировать в pfs каждый не вижу смысла.
Вот это я не совсем понимаю... По Вашей задумке, какое место в PRA должен занимать функционал PFS? И что такое "pfs-mono"?
Если основной формат пакетов PKG - то зачем PFS? В этом случае, получается, достаточно обычного SFS (без специфичных для PFS метаданных).

Утилиты PFS писались с учётом использования в системе PFS как основного формата пакетов.
Пакеты других форматов перед использованием должны быть конвертированы в PFS, чтобы не было путаницы. При этом создавать SquashFS файл совсем не обязательно. Например скрипт, устанавливающий PET-пакеты не создаёт промежуточных файлов, а просто ставит пакет в систему и генерирует для него каталог в /etc/packages/install, чтобы пакет можно было удалить штатными средствами PFS. Этот механизм можно адаптировать и к любому другому типу пакетов.

Можно конечно сделать наоборот - при подключении или установке PFS автоматически создавать файлы в /var/lib/pacman/local, т.е. имитировать для pacman-а его родные пакеты. Для установки/удаления тоже использовать pacman. Но мне такой путь не кажется оптимальным.

Оффлайн sfs

  • Администратор
  • Ветеран
  • *****
  • Сообщений: 33956
  • Репутация: +231/-0
  • Автор темы
    • PuppyRus-A
Re:PRA + pfs-utils
« Ответ #13 : 20 Август 2013, 10:21:26 »
какое место в PRA должен занимать функционал PFS?
Подключение\ отключение, установка\удаление, склейка\расклейка
А больше он ничего и не может
Для создания мета-модулей софта он удобен. Им проще. Хотя бы на переходный период
Т.к. pfs исключительно наш формат - варианта юзать чужую репу без чужого ПМ у нас нет
Получается pfs сможет работать только со своей репой
Если ее компилить самим - какой-то смысл доводить pfs до полноценного ПМ (скачка, зависимости) есть
Только сил на всю свою репу нет и смысла тягаться с pacman apt rpm - я тоже не вижу

"pfs-mono" - одиночный (не pfsmerge) pfs
Перепаковывать все пакеты в pfs и склеивать - чем это лучше собранного ПМ и запакованного в pfs-mono?

Получается - правильный путь интеграция PR наработок в арч (AUR, своя арч-репа)
достаточно обычного SFS (без специфичных для PFS метаданных).
Без склейки в модулях софта пока тяжеловато
Я далеко не гуру арча. Не владею всеми его средствами
Можно конечно сделать наоборот - при подключении или установке PFS автоматически создавать файлы в /var/lib/pacman/local, т.е. имитировать для pacman-а его родные пакеты. Для установки/удаления тоже использовать pacman. Но мне такой путь не кажется оптимальным.
Выше - я и пытался донести идею
PRA сейчас микс pacman и pfs
Если ничего не вырезаешь в pkg (и dev часть тоже)- в pfs надо иметь /lib/pacman/local
Вырезаешь - удаляй /lib/pacman/local
Если не придерживаться этого правила - сломаем pacman и потеряется смысл перехода PR->PRA

Оффлайн Zay

  • Почетный участник
  • Ветеран
  • *
  • Сообщений: 1536
  • Репутация: +25/-0
Re:PRA + pfs-utils
« Ответ #14 : 21 Август 2013, 10:51:19 »
Пока что я, честно говоря, не проникся идеей. Возможно - просто не понимаю преимуществ.
У меня впечатление что концепция PRA не продумана до конца.


"pfs-mono" - одиночный (не pfsmerge) pfs
Т.е. файл PFS с одним пакетом внутри.

Перепаковывать все пакеты в pfs и склеивать - чем это лучше собранного ПМ и запакованного в pfs-mono?
1. Возможность разделать на пакеты обратно (иначе зачем тогда PFS?).
2. Вероятная путаница и дублирование файлов в разных пакетах.

Т.к. pfs исключительно наш формат - варианта юзать чужую репу без чужого ПМ у нас нет
Получается pfs сможет работать только со своей репой
Не обязательно. При разработке PFS-utils я учитывал возможность использования PET-пакетов, по идее можно сделать адаптацию и для пакетов арча.


Когда возникла идея использования чужих пакетов совместно с PFS я представлял себе это примерно так:

Все пакеты в системе являются пакетами формата PFS (с /etc/packages).
Подключение / Отключение / Установка / Удаление - это функции нашего "диспетчера PFS".

При использовании пакетов других форматов - выбор "Установить, как будто это PFS" или конвертировать в PFS-файл.
Загрузка чужих пакетов из сети - с помощью чужого ПМ, с последующей конвертацией в PFS налету, либо установкой (опять же как PFS).
При загрузке пакетов с зависимостями - делать многопакетный PFS-файл. Один исходный пакет - один пакет в контейнере PFS (или даже два: пакет и dev-пакет).

Информацию о зависимостях можно было бы брать из чужих пакетов и прикреплять к PFS, либо игнорировать (пусть об этом думает ПМ при команде "скачать Firefox с зависимостями").