Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High i/o load after unit start #345

Open
Pheidologeton opened this issue Nov 21, 2022 · 3 comments
Open

High i/o load after unit start #345

Pheidologeton opened this issue Nov 21, 2022 · 3 comments

Comments

@Pheidologeton
Copy link

I have disabled crashrecovery in psd.conf, but psd still calls find to find crashrecovery in the home folder. Since I have a lot of small files (40+ million) in /home/user, this takes a long time and causes a lot of i/o.

@albel727
Copy link

The person at #318 had the right idea: find should take -maxdepth 1 switch and search for the recovery dirs with the right prefix, i.e. all usages of find should change like

-find "${DIR%/*}" -type d -name '*crashrecovery*' -print0
+find "${DIR%/*}" -maxdepth 1 -type d -name "${DIR##*/}-backup-crashrecovery-*" -print0

This drastically reduces I/O and makes the rm -rf safer, when the backup dir happens to be in $HOME.

@graysky2
Copy link
Owner

@albel727 - thanks for pointing that out. Can you please try the latest commit and report back. Seems to work for me with limited testing. Would be nice if someone could test with firefox/multiple profiles.

@graysky2 graysky2 reopened this May 25, 2024
@albel727
Copy link

I see your latest commit, but I can't test it at this time. I can only say, that I've been running similarly patched version myself and it worked for me too.

The only problem with this commit as it is, is that it worsens another bug, which was mentioned in #318 too. Namely that enforce() forgets to call load_env_for $browser and set the $DIR variable and hence uses some random $DIR, that happened to stuck from some previously invoked function. It almost didn't matter before, because *crashrecovery* pattern was sloppy enough to find most backup dirs anyway. But with the new exact search this is no longer the case and so it will lead to most backup dirs no longer getting removed.

This is easy to fix by just adding the correct load_env_for with a loop over $DIRArr or even by unifying enforce() and cleanup() (the latter is basically the former with $BACKUP_LIMIT = 0).

Compare the wrong code in enforce()

for browser in "${BROWSERS[@]}"; do
local CRASHArr=()

with the correct code in cleanup()
for browser in "${BROWSERS[@]}"; do
load_env_for "$browser"
for item in "${DIRArr[@]}"; do
DIR="$item"
local CRASHArr=()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants