Сохраненка.pfs create-save-pfs

[Nikson IiI]

И снова здравствуйте.

Мне видится чуть ли не катастрофа Заранее извините, если напутал, с Линуксом и Паппирусом знаком недавно.

Суть, кажется - баг: Паппирус теряет данные. Ибо неверно работает объединение с прошлой сохраненкой, а если их несколько - все еще хуже.

Для чистоты эксперимента берем свежую систему. Анализ на основе наблюдений.


I. Пропадание файлов:
1) Создаем файл "X", сохраняемся, перезагружаемся.
2) Удаляем файл "X", сохраняемся, перезагружаемся.
3) Создаем файл с тем же именем "X" (*), туда диссертацию пишем, сохраняемся с объединением, перезагружаемся.
4) Файла "X" нет, диссертация пропала! Даже если создадим ее заново, сохранимся с объединением и перезагрузимся - снова не увидим! (**)
*) Система может не дать сразу создать файл с тем же именем. Тогда можно сначала, например, создать файл "Y".
**) На самом деле файл лежит в сохраненке, можно достать его монтировкой. Что абсолютно не айс, ведь это может быть незаметная настройка проги, хз где лежащая.

Анализ: при удалении файла инфа об этом записывается в сохраненку в виде соседнего файла ".wh.X". Самим же удалением занимается система при загрузке сохраненок, анализируя последовательность их слоев. А вот объединение не учитывает многослойность! Ему при появлении нового файла в том же модуле следовало бы уничтожать ".wh.X" от старого - в этом ошибка. Поэтому, очевидно, что если ранее был создан некий файл, а потом удален (такое часто происходит с конфигами), то новый файл с тем же именем система больше не увидит при использовании объединения. Ведь он будет в одной сохраненке (в одном слое) с инфой о якобы его удалении.

Исправление вижу в ручном поиске в объединенной сохраненке лишних флагов ".wh." и, по возможности, удаления их вместе со старым файлом.


II. Старые версии файлов:
1) Создаем файл "Z", можно записать туда пару букв, сохраняемся, перезагружаемся.
2) Пишем доклад президенту в файле "Z", сохраняемся без объединения, перезагружаемся.
3) Читаем, ничего не меняя файл "Z", радуемся, сохраняемся с объединением, перезагружаемся.
4) Открываем файл "Z", а там пара букв, доклад президенту пропал! (*)
*) На самом деле доклад не пропал - он лежит в .old, что слабое утешение по тем же причинам.

Анализ: предыдущие сохраненки, объединяясь, наслаиваются в неверном (обратном) порядке.

Исправление возможно только если остались .old необъединенных сохраненок:

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

Однако, с учетом пропадания файлов, необходимо послойно обрабатывать ".wh."!


Так что, если все верно - вывод однозначный: объединение сохраненок приводит к потере данных и не должно использоваться! Лично я, например, буду переходить на иные варианты сохранения (хотя и их теперь хочется проверить). И для меня, начинающего линуксовода, очень прискорбно, что присутствуют такие серьезные проблемы у быстрого, мобильного и неубиваемого Паппируса...

Кстати, дико подозреваю, что подобные случаи уже были: http://forum.puppyrus.org/index.php?topic=17250


P. S. Возвращаясь к древнему топику:

напрягает в pfs-util:
При автозагрузку модулей - слои aufs по алфавиту
При pfsmerge - наоборот

И вот еще (читать про обратный порядок): http://forum.puppyrus.org/index.php?topic=14390.msg78263#msg78263
Не взаимосвязаны ли эти все эти скрипты, может оттуда и пошла ошибка?

[paulus]

Лично я, например, буду переходить на иные варианты сохранения (хотя и их теперь хочется проверить).

Согласен с вами. Самый нормальный вариант changes=/pra

[DdShurick]

Самый нормальный вариант changes=/pra

Самый нормальный вариант:

Код

/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)

Универсален для всех линуксов.

[paulus]

Самый нормальный вариант:

Код

/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)

Можно уточнить, как это поможет при работе в copy2ram?

[DdShurick]

copy2ram

Не использую, ИМХО - "масло масляное" (избыточен).
/changes сохраняет все изменения на носителе, /home только пользовательские и раздел может быть общим с другими линуксами, даже "большими". Необходимые системные настройки в save.pfs, их менять приходится не часто.

[sfs]

I. Пропадание файлов:
1) Создаем файл "X", сохраняемся, перезагружаемся.
2) Удаляем файл "X", сохраняемся, перезагружаемся.
3) Создаем файл с тем же именем "X" (*), туда диссертацию пишем, сохраняемся с объединением, перезагружаемся.
4) Файла "X" нет, диссертация пропала!

Да. В итоге имеем в сохраненке .wh.X и Х ,что при подключении дают пустоту
Файл Х не пропал (можно выдернуть из сохраненки), но его не видно
Тут если только написать скрипт, который циклом удаляет .wh. для всех файлов сохраненки ( при большой сохраненке будет отрабатывать долго)
Есть другие идеи?

По замыслу save.pfs - для заморозки своих настроек. Хранить там документы будет неудобно. Лучше сохранять их отдельно в отдельное место

Самый нормальный вариант changes=/pra

Универсальный - да. Но с убиваемостью плохо (можно делать бэкапы
Каждому своя сохраненка (смотря что и в каком количестве хранить)

/changes сохраняет все изменения на носителе, /home только пользовательские и раздел может быть общим с другими линуксами

Тогда уж удобнее вынести папки с настройками отдельных приложений (типа браузеров) и в сохраненке держать симлинки
Один home для разных дистров - спорный совет. Могут быть глюки. Как минимум у юзера во всех ОС должен быть одинаковый логин UID GID (это жн касается и симлинков на профили браузеров)

[sfs]

Тут если только написать скрипт, который циклом удаляет .wh. для всех файлов сохраненки ( при большой сохраненке будет отрабатывать долго)

Циклом перебирать .wh.(их меньше) ,а не файлы

[DdShurick]

Тут если только написать скрипт, который циклом удаляет .wh.

Давно написано
/usr/bin/mksavesfs:

Код

# DdShurick GPL-v2 18.03.16
..........................
#Удаляем "затенённые" (отмеченные как удалённые) файлы и каталоги.
find /tmp/savesfs-root -mindepth 2 -name .wh.* | while read WH
do
F=$(echo $WH | sed 's/\/tmp\/savesfs-root//;s/.wh.//g')
	if [ -e "/initrd/pup_rw$F" ]; then
	 rm $WH #если удалённый файл заново создан, удаляем .wh.*
	else
	 [ -e "/tmp/savesfs-root$F" ] && rm -r /tmp/savesfs-root$F #если ранее сохранённый файл удалён, удаляем его.
	fi # если .wh.* относится к нижним слоям - ничего не делаем
done
......................

[sfs]

Код

for i in `find /tmp/makesfs -name ".wh.*"` ;do
    i2="`dirname "$i"`/`basename "$i" |sed 's/.wh.//`"
    [ `stat -c %Y "$i2"` -gt `stat -c %Y "$i"` ] || rm "$i"
done

Так покороче будет и stat - дистронезависимо. /initrd/pup_rw в ПРА нет
nikson_iii - спасибо +

[DdShurick]

/initrd/pup_rw в ПРА нет

В Richy теперь тоже, есть стандартизованное /initrd/changes

Код

#если удалённый файл заново создан, удаляем .wh.*
#если ранее сохранённый файл удалён, удаляем его.

Эту сортировку stat обеспечит?

[Nikson IiI]

Тут если только написать скрипт, который циклом удаляет .wh. для всех файлов сохраненки

Удалять .wh. из прошлых сохраненок нужно для всех новых файлов (из более высоких слоев). Иначе восстановятся вообще все.

Есть другие идеи?

Немножко ускориться можно если искать .wh. в старых pfs.files, а не в файловой системе.

Но значительное ускорение всего процесса сохранения придет если объединение (и наши операции) производить в RAM (если свободна), а на носитель - только упаковывать.

[sfs]

Удалять .wh. из прошлых сохраненок нужно для всех новых файлов

ускориться можно если искать .wh. в старых pfs.files, а не в файловой сисеме.

так и сделал

ускорение всего процесса сохранения придет если объединение (и наши операции) производить в RAM

Если создание сохраненки даже в gz идет ощутимо долго - явный признак того, что удобнее будет сохранение в папку
Сейчас сохранение идет через tmp файл на загрузочном носителе. Это наиболее универсально.
Не хочу усложнять

[Nikson IiI]

Удалять .wh. из прошлых сохраненок нужно для всех новых файлов
ускориться можно если искать .wh. в старых pfs.files, а не в файловой системе.

так и сделал

create-save-pfs.gz

К сожалению, не знаю этот язык и плохо понимаю скрипт - эти функции там уже были или где-то лежит обновление?
И поправил: новыми файлами являются не только пришедшие из changes, а еще и все из более высоких (относительно .wh.) слоев прошлой сохраненки.

#если ранее сохранённый файл удалён, удаляем его.
Эту сортировку stat обеспечит?

Присоединяюсь к вопросу. Если я правильно понял, речь о ненужных файлах в сохраненке (удаленных). Ведь на случай отката существуют .old, а ".wh.X" + "X" занимают только место и время на упаковку-rw-распаковку.

Предлагаю после каждого наслоения при обнаружении ".wh.X" в pfs.files, по-возможности, удалять "X". Сам ".wh.X" должен оставаться для уничтожения потенциальных "X" из нижних pfs (возможно, отключенных и невидимых).

ускорение всего процесса сохранения придет если объединение (и наши операции) производить в RAM

Если создание сохраненки даже в gz идет ощутимо долго - явный признак того, что удобнее будет сохранение в папку
Сейчас сохранение идет через tmp файл на загрузочном носителе. Это наиболее универсально.
Не хочу усложнять

Почему удобнее? Сохранение в папку без сжатия не всегда увеличивает скорость, особенно на мощном CPU при использовании флешки. Ведь увеличивается объем + сохраняется в виде множества мелких файлов (например, конфигов). И то и другое существенно тормозит скорость чтения-записи. Остальные преимущества модулей также известны.

Через tmp - медленно, когда загрузочный носитель - флешка (PRA - как мобильная система). И в чем особая универсальность? Например, если нет места для tmp?

Насколько я понимаю, наслоение (и удаление .wh.) идет копированием в tmp на носителе.
Я предлагаю делать тоже самое, только симлинками в RAM-каталоге.
Быстро, не требует памяти и, вроде бы, универсально.
Конечно, Ваше право не усложнять

P. S.

предыдущие сохраненки, объединяясь, наслаиваются в неверном (обратном) порядке

Не забылась бы эта ошибка. Она мне всю системку искорежила... Слава богу, остались .old

[sfs]

не знаю этот язык и плохо понимаю скрипт

А это и не требуется.
Распакуйте аттач и положите в /rootcopy/usr/local/bin и протестируйте что изменилось

tmp на носителе удобнее, потому что задача найти там место проще, чем добавить RAM
Про симлинки Ващу идею не понял

[Nikson IiI]

Насколько я понимаю, наслоение (и удаление .wh.) идет копированием в tmp на носителе.
Я предлагаю делать тоже самое, только симлинками в RAM-каталоге.

tmp на носителе удобнее, потому что задача найти там место проще, чем добавить RAM
Про симлинки Ващу идею не понял

Возможно, я новичок - и ошибаюсь, но ведь можно вместо копирования создавать жесткие/символьные ссылки?
То есть, при объединении сохраненки не копировать, а ссылаться на /mnt/live/memory/images/090-save-*.pfs/?
При этом и RAM добавлять не потребуется.