I’ve noticed that as time goes by (especially when using nightlies), the previous system states start consuming a fair bit of disk space. There is a cleaning utility in HaikuDepot called FilWip wherein deleteing them can be done manually. However, perhaps it would be better if there are settings for getting the system to automatically do this instead as self-maintenance.
The settings could be the following:
- System state count limit (e.g.
3 snapshots only,
5 snapshots only, etc.)
- Disk space size limit (e.g. Delete snapshots at
500 MiB, Delete snapshots at
2.5 GiB, etc.)
- Cleaning period (e.g. Clear snapshots every
3 days, Clear snapshots every
6 months, etc.)
Would like to hear feedback on this idea and suggestions on other possible settings.
Please vote for the ticket if you think it’s important.
Sorry I thought I would have worked on this already.
It’s not really documented in that ticket but my current thinking is that the best approach for choosing states to delete is to consider both the number of states and the age of the states. This ensures that users which do frequent or infrequent updates are both properly handled. So something like delete all states older than 30 days, but ensure 10 are kept, where the 30 days and 10 states are configurable. Plus the whole setting to delete the states can be toggled and probably will default to off for now.
But I would need to do a lot of testing and look more deeply into how the states depend on each other, as noted some in the ticket.
If I don’t use a program in 30 days I don’t like the settings to be removed. A clean up can be handy where you can choose to set the date by your self.
One thing I do misses are when I uninstall a program with HaikuDepot I don’t think it will remove my other dependency packages and not the setting for it? That would be nice
To be clear this is about cleaning system states (snapshots), not about program settings being reset.
I do not like things to happen automaticaly…
You updade manual and therefore deinstall manual is ok!
The HAIKU way should be like it is now!
If the user do nothing, nothing will happen!
I do not like the OS is going to do something without my knowledge!
You can manually inform the user to manually delete old files if necessary on the forum or Homepage or the Calendar!
I hate auto delete or install!
I don’t think this is needed for the brta releases, but for nightly it might be nice.
I would like to add that 10 (or 3 in the example on top) states is way too low a number, just browsing through haikudepot and installing some games will quickly get you over that number. Most states are just text files for the set of software anyway (and in some cases reinstalling old software picks them from previous states too)
Personally i wouldn’t use such a feature, but i think a number of 300 states or so could work, but perhaps a disk size limit is the best option indeed.
It goes about the administrative files right?
Humdinger and myself creates a bootscript to manage this files in the past. I does not know if it is running anymore, because i does not use it, but can be an idea and start up for future handling.
Nice script @lelldorin, maybe an option to “move” the files somewhere else instead of deleting them directly would be better, if on a reboot problems arise one would still have an option to restore them?
But that wouldn’t solve the issue of disk space that removing old system states would. I’m fine with the option of moving them somewhere else, but not outright using that in lieu of deletion.
At times I have quite a lot of “states” due to building/installing/uninstalling, and once in a while I move the old states to another place, after some reboots and things are still ok I remove them (ps, disk space is not really a problem here)
If that’s to a different disk, sure. But it doesn’t really work if they’re just being moved to another place on the same disk.
Didn’t know that one (should check it out at some point), so you mean like if I move them to “~/backup” the states are still being seen?
No, but they’re still taking up disk space.
I can make a little gui for managing
My hope would be the way I implement this will be useful for most people. The cleanup functionality will of course be written in C++ in the Package Kit and besides the automatic setting it could also be run manually maybe with
pkgman cleanup or a similar name. That could either use the current (or default) settings which are exposed in a GUI preference somewhere, or they could be passed on the command-line to override those settings. There could also be a menu or button in HaikuDepot, or in whatever app since ideally this is just exposed as a Package Kit API.
I feel like that will give maximum flexibility and there will hopefully not be a need for outside utilities for this. Plus of course whoever wants to keep all their states can just never turn this on. But I feel this is something that should be handled by the operating system.
Maybe another aspect would be consolidating state directories (making many states into one), but to be honest I need to spend more time learning how those state directories work for both cleanup and consolidation.
With all this said it is also very important I actually work on it and not just talk about it
Perhaps a setting saying keep last 3 version or so, with that option I don’t mind it being automatically.
Check out this (wrong approach, dismiss)'haistate' command line tool to manage system states (proof of concept)
This was a wrong approach because I thought that Haiku’s states were somewhat like snapshots, so we could get rid of old snapshots not in use. Actually states, if I understood @PulkoMandy correctly are just plain text files that keep a “diff” of packages compared to the prior state. I was thinking about the Fedora Silverblue deployment approach, but that does not apply here at all. In fact, I was doing some Python tool to manage that, but stopped due to the wrong approach taken.
Not sure if it makes sense, but it could be an idea to have a tool, be it command line, be it gui, that updates the state to “merge” all diff state files into an actual state that has proven stable with all packages that are active at the moment thus creating a “new complete state” that has no prior dependencies. That new state could be saved by the user as “non deletable” until the user decides to move forward. Also, that new state could be the base for further diff states? Just thinking aloud.