mkpfs v.3 (pfsmerge-dir v.2) Неудобства перепаковки составного модуля

[sfs]

Это возможно ответ на

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

[betcher]

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

[betcher]

Жалко было удалять кусочек со сборкой модуля без ауфс. Убрал его под ключик -i / --in-place (по аналогии с sed -i).

[sfs]

ключик -i / --in-place

отлично!

Тестирую на aufs:
1. pfsextract -d testmodule.pfs - остается /mnt/tmpfs1 ; pfsextract - мой сегодняшний
2. mkpfs -d testmodule && unsquashfs -d 2 testmodule.pfs - в папке 2 убиты права на /empty (стали root). Вчера днем было ок
Видимо - результат вечерней правки под tmpfs. Сами поправите или нужна помощь?
Вики не пора переделывать?

[betcher]

убиты права на /empty

Права на пустые папки сменились? Не соображу с какой правкой такое может быть связано.

[sfs]

Права на пустые папки сменились?

Да. Причем те же операции с mkpfs  на ext - все ок
В моем эксперименте aufs - это сохраненка в памяти

[sfs]

Добавил в addlayer -a к cp - вылечились права.
Может mv?

[betcher]

cp -a  Ларчик просто открывался
Я не против mv, боюсь только ситуации, когда мы папку перенесли, модуль по какой то причине не собрался, а delaufs все затерло. С cp безопаснее.

[betcher]

Еще момент на счет mv. Копируем в tmpfs мы в addlayer, а вернуть обратно можно только после завершения mkpfs. То есть нужно как то сохранять список того что нужно вернуть и куда.

[sfs]

Я еще глубоко не смотрел код, но мне кажется
1. создали tmpfs
2. mv на tmpfs
3. сделали, что хотели
4. mv обратно
5. разобрали tmpfs
когда изначально aufs - это тоже tmpfs ничего не теряем, а экономим скорость и память
когда изначально aufs - это не память - мало что выигрываем, а можем все потерять
Может cp\mv - в зависимости от винт\ram или ключом?

1. pfsextract -d testmodule.pfs - остается /mnt/tmpfs1 ; pfsextract - мой сегодняшний
Сами поправите или нужна помощь?
Вики не пора переделывать?

[betcher]

Дело в том что каждый каталог подключается отдельно в цикле addlayer'ом, то есть зависимо от списка часть папок может быть подключена сразу, а часть из tmpfs. Потом собираем модуль. И только потом нужно разобрать tmpfs. А что и куда возвращать не известно.
То есть все это не невозможно, но прилично усложнит.
delaufs на предмет удаления мусора починю. Как только до компа доберусь.

[sfs]

все это не невозможно, но прилично усложнит.

Я правильно понял - доп. копирования автоматически включаются при определении aufs?
Думаю - наиболее востребована на практике будет пересборка составного модуля:
pfsextract -d + mkpfs -d
При больших модулях - в памяти будет ощутимо быстрее. Может этот случай как-то особенно оптимизированно обыграть
Тут особых сложностей с возвратом mv не просматривается

Вики не пора переделывать под версию 3?

[betcher]

Давайте погоняем как есть, если потребуется оптимизация будем думать. Возможно достаточно для вашего случая будет расширить работу с ключиком -i до сборки составных модулей путем mv в одну папку после mklist. Я к тому, что если вы знаете что будете распаковывать править и запаковывать, то можете распаковать сразу в /tmp.
По вики торопиться не стоит. Еще половину утилит не смотрели даже.

[sfs]

можете распаковать сразу в /tmp.

Да - в ПРА /tmp - это tmpfs и не aufs. Кстати - это решит все проблемы без усложнений...

По вики торопиться не стоит. Еще половину утилит не смотрели даже.

Мы свели все утилиты работы с составными.pfs в 2 скрипта. Остается только подкл\откл и т.п - там ничего не изменилось

[betcher]

Pfsload надо перевести на addlayer. Сократится вдвое. Хочу еще pfsinstall /dir сделать, то есть mklist dir / добавить. Может еще чего всплывет.