EXIT cheatcode/multiple saves...

[stifiling]

Hello,

I was wondering what's the command, or what's the process that takes place amongst reboot when using the EXIT cheatcode to save the changes at the end? Whatever this command, or procedure is...couldn't there be a script of some sort written, or a cronjob...to have this command executed once every 30 mins or so?

if possible this would minimize even further, the chance of data loss, if a rare situation like a kernel panic or power loss to the machine takes place. It will also free up the RAM again every 30 mins.

Puppy linux has a script called snapmergepuppy that does exactly this. Saves the changes every 30 mins, and clears the RAM out so it doesn't fill up. It's also set up to know to run when RAM is low, even if it hasn't been 30 mins, and run then to free the RAM.

[brokenman]

It's an interesting idea. changes=TIME:10 to save changes every 10 minutes. What do you think fanthom?

[fanthom]

current implementation (changes on EXIT) performs a sync during shutdown when /union is dismantled. this method is the best as is fully safe.
syncing between top branch (rw sitting on tmpfs) and lower branch (fake 'ro' sitting on real filesystem) during porteus session is bit risky as we will be modifying lower branch directly. in Porteus we are using 'udba=none' flag by default and aufs man page says:

Code: Select all

udba=none
Aufs trusts the dentry and the inode cache on the system, and never test about UDBA. With this option, aufs runs fastest, but it may show you incorrect data. Additionally, if you often modify a branch directly, aufs will not be able to trace the changes of inodes on the branch. It can be a cause of wrong behaviour, deadlock or anything else.

when performing rw->ro sync during porteus session i'll try to remount '/' with udba=notify flag during sync and see how it goes:

Code: Select all

udba=notify
Aufs sets either ’fsnotify’ or ’inotify’ to all the accessed directories on its branches and receives the event about the dir and its children. It consumes resources, cpu and memory. And I am afraid that the performance will be hurt, but it is most strict test level. There are some limitations of linux inotify, see also Inotify Limitation. So it is recommended to leave udba default option usually, and set it to notify by remount when you need it.

also - dont want to make changes= cheatcode syntax too complicated so will use existing /etc/changes-exit.conf (which we use for specifying folders which should be synced) for settings like 'time interval' and 'low RAM limit'.

we are reaching 2.1 final and need to test this feature against aufs stability so not sure if will push it to 2.1 or the version after 2.1.

thanks for suggestion.

[tome]

Hi,
My suggestion for saving changes is to add 3 launchers to menu: Save changes, Shutdown saving changes and Shutdown discarding changes.
You can also add possibility for mounting and making modules in .dat format (like changes.dat) - without compression and read only.

[brokenman]

You can also add possibility for mounting and making modules in .dat format (like changes.dat) - without compression and read only.

The Porteus Settings Centre can be used for creating/modifying save.dat files. These can also be mounted during a live session (providing they are not in use).

[fanthom]

@brokenman
i think tome referred to .dat containers being treated as modules (but not compressed)

@tome

My suggestion for saving changes is to add 3 launchers to menu: Save changes, Shutdown saving changes and Shutdown discarding changes.

i still prefer cheatcode+changes_exit.conf for few reasons:
- works also in runlevel 3
- some users may use 'reboot' command while in GUI (i always do that) and wont have to remember to choose correct option from menu
- cheatcode will work also when user press 'ctrl+alt+del' on VT1-6

i'll definitely introduce 'dump_session' script for saving changes 'in this very moment'. this could work as your 'Save changes' launcher (if i understood its purpose correctly)
'Shutdown saving changes' is implemented already with 'changes=EXIT:' cheatcode
'Shutdown discarding changes' is also implemented as it's enough to delete /mnt/live/tmp/changes-exit file (or press any key when prompted during shutdown). you could easily create a launcher which asks for root password -> removes /mnt/live/tmp/changes-exit file -> switches to runlevel 0/6.

You can also add possibility for mounting and making modules in .dat format (like changes.dat) - without compression and read only.

yes - this could be done but my choice goes for xzm for few reasons:
- .dat has fixed size (does not matter if you fill it fully or just with 1%)
- .xzm is compressed thus smaller and faster to read
- .dat must have specific size while size of xzm has no such limit (easier to add new files to it)

please explain the advantages of .dat over .xzm

[tome]

I shutdown more often my laptop without saving changes (I must press any key) so for me there will be more useful to press any key if I want to save changes (other cheatcode?). Furthermore I share my laptop with other users and therefore I prefer not saving changes as default or show them launcher on desktop (or in applications menu) instead to remember pressing any key.

@fanthom
why .dat
- making .xzm (~1 Mb; ~x Mb) module uses 100% CPU for a long time (~1 min; ~x^x min) - it can kill my machine
- if I want change something in .xzm module I must (re)create new or use changes.dat (xzm module has fixed everything - files, size(like dat) etc - it's also advantage)
-low compression ratio for some files (or already compressed)
-more choice, you can use xzm and dat (new modules-dat folder in porteus or side by side xzm and dat in modules?)

[fanthom]

I shutdown more often my laptop without saving changes (I must press any key) so for me there will be more useful to press any key if I want to save changes (other cheatcode?).

i'm against new cheatcodes to not makes things unnecessarily complicated. as i wrote before - it's enough to delete /mnt/live/tmp/changes-exit to prevent saving changes during shutdown.
to make things automated you could create a script called 'reboot-clean':

Code: Select all

#!/bin/bash
rm -f /mnt/live/tmp/changes-exit
reboot

and call it from terminal or your custom GUI launcher.

Furthermore I share my laptop with other users and therefore I prefer not saving changes as default or show them launcher on desktop (or in applications menu) instead to remember pressing any key.

you could create additional entry in your bootloader config for 'guests' with changes being saved, not being saved, saved at shutdown or however you like.

i see your points regarding .dat vs .xzm
i'll add a support for .dat containers to linuxrc, mloop and aufs-insert. this way the containers can be used the same way as squashed modules. two things to note:
- .dat files must be still named as .xzm (to avoid updating dozen of docs and writing separate code) so it's probably wise to create folder like: /porteus/modules/dat and keep all .xzm containers there (so they wont mix up with normal .xzm)
- if .xzm container was activated during boot then you wont be able to mount it from porteus session as it has a real filesystem mounted by initrd already (different body). you will see following message in /var/log/dmesg:

Code: Select all

[   79.043234] XFS (loop10): Filesystem has duplicate UUID 86bf39ee-fa3f-4de5-a068-a17da83834a6 - can't mount

so in order to make the modifications to it you'll have to:
deactivate container -> mount it with 'mloop' utility -> make modifications in /mnt/loop-> activate again (pretty much the same actions as when remastering normal .xzm)

btw: we could allow inserting .xzm folders instead of .xzm containers (aufs is truly flexible in this matter) so modifications would be even easier and problem of fixed container size would not exist, but i'm worrying that some users would keep them on windows filesystems and permissions/symlinks would not be preserved so let's stick to the containers for now.

thanks for suggestions.

[stifiling]

i'll definitely introduce 'dump_session' script for saving changes 'in this very moment'.

This is the only piece that i need. Thanks for considering the idea. Porteus = Great!

[brokenman]

Open a terminal and type: save-session

This uses all processors to create a module of your current changes (you get a GUI first). If you have multiple processors you can edit the script to use mksquashfs instead of dir2xzm directly and limit the processor.

mksquashfs -processors 1 /path/to/dir /tmp/module.xzm

Interesting idea about .dats, I guess it has its pros and cons.

[tome]

bootloader config for 'guests' with changes being saved, not being saved, saved at shutdown or however you like.

I think it should work: changes not being saved default (cliexec=rm-changes-exit-script) but loaded with cheatcode "changes=EXIT:" and during session 'guest-dump_session' script for saving changes (other permissions for /mnt/live/tmp for doing that without password)

thanks a lot fanthom