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.

Sign up for GitHub

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

Jump to bottom

Better support for scheduling wrt AC power #42

Open
kdave opened this issue Jan 15, 2018 · 15 comments
Open

Better support for scheduling wrt AC power #42

kdave opened this issue Jan 15, 2018 · 15 comments
Labels
RFC
Milestone
v0.5.2

Comments

@kdave
Copy link
Owner

kdave commented Jan 15, 2018

This is forked from discussion in issue #29, cc @sten0

  • ConditionACPower=yes in the timer units, because maintenance operations will needlessly deplete battery life on laptops, and servers that are on emergency UPS power should probably defer as well
  • Combined with anachron-like behaviour so that these tasks will run when AC power is restored
  • Support for running these tasks in one-shot mode. I believe this is useful for the following situation: a company usually scrubs on the 1st of the month, but an immanent product launch will ensure that the servers will be very busy for at least the first week of the next month. I'm not sure if systemd supports deferring scheduled tasks, but it definitely has a mechanism for checking if a job has run in the last 'now -30 days'. One-shot mode means the scrub can be manually triggered at a time before the surge in traffic to best assure quality of service. The unit for check on the 1st of next month exits with "scrub unneeded". The unit for check on the 1st of next next month finds that a scrub has now been completed in ~37 days or so and executes as expected.
@comio
Copy link
Contributor

comio commented Jan 19, 2018 •
edited

  • ConditionACPower=yes in the timer units, because maintenance operations will needlessly deplete battery life on laptops, and servers that are on emergency UPS power should probably defer as well
  • Combined with anachron-like behaviour so that these tasks will run when AC power is restored

from my understanding, systemd silently skips the timer. A trick is to create a power-ac target and a battery target and inject the power-ac dependency. This is not obvious and we need also to add udev rules in order to activate the targets on demand.

I will check for deferred task scheduling... "Persistent=true" can be useful, I think and it is already used.

Persistent=

Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer is activated, the service unit is triggered immediately if it would have been triggered at least once during the time when the timer was inactive. This is useful to catch up on missed runs of the service when the machine was off. Note that this setting only has an effect on timers configured with OnCalendar=. Defaults to false.

@sten0
Copy link
Contributor

sten0 commented Jan 21, 2018 via email

@comio
Copy link
Contributor

comio commented Jan 24, 2018

Hi @sten0 ,

ConditionACPower=yes will just skip the trigger if you are on battery. I think that is not good for laptops because will be an high probability to skip indefinitely the job.
Regarding the power-ac and battery target... at this time these are distro specific. :/

@comio
Copy link
Contributor

comio commented Jan 24, 2018 •
edited

I had this idea:

  • Don't insert ConditionACPower= in the job and call the script also on battery
  • The script will check itself the ac power status, waiting (like loop/check AC/sleep/do again) before doing the required jo
  • When AC Power will be present, the script will continue with the required job (ie defrag)

caveat: how we can check the ac power in a portable way?

cat /sys/class/power_supply/*/status

something like this could help

while [ $(cat ${STATUS_FILE}) != ${AC_POWER_STATUS} ]; do
   sleep ${SLEEP_TIMEOUT};
done;

@sten0
Copy link
Contributor

sten0 commented Jan 30, 2018

That looks ok to me, and your method also accommodates those who don't use systemd ;-) That said, the user who submitted a Debian bug report I received titled "Blindly assumes systemd" already has his own scripts, so I wonder systemd and openrc users are not the target audience...

Is there already a queuing mechanism that will prevent defrag, balance, and scrub from running simultaneously when the laptop is plugged in? One thing I like about the systemd approach it is supposed to allow stuff like defrag.service:Before=balance, balance.service:Before=scrub, which ought to prevent three IO intensive jobs from being run at once. Assuming these actually work, it seems like an elegant approach. It's a shame there isn't a ConditionACPower=yes||wait/sleep...

Also "cat /sys/class/power_supply/*/status" might be better as: cat /sys/class/power_supply/AC/online (prints 1 when there is AC and 0 when unplugged)
because I've seen cat /sys/class/power_supply/BAT?/status print Charging, Discharging, and Unknown.

@comio
Copy link
Contributor

comio commented Jan 30, 2018

ConditonACPower is just a "skip-only" condition and cannot help. systemd will never add a "ConditionACPower=wait" or similar.
To avoid multiple run (but this is another question), I usually create a lock file/directory for the resource and wait on it.

@comio
Copy link
Contributor

comio commented Jan 30, 2018

Can we add this helper function to btrfsmaintenance-functions:

# function: wait_ac_power
# parameter: timeout
#
# wait until ac power goes online
wait_ac_power() {
        local timecount=0
        local timeout=0
        [ ! -z "$1" ] && timeout=$1

        if [ -f /sys/class/power_supply/AC/online ]; then
                while [ $(cat /sys/class/power_supply/AC/online) -ne 1 ]; do
                        # AC is not online
                        [ $timeout -gt 0 ] && [ $timecount -ge $timeout ] && return 1
                        sleep 1s
                        timecount=$((timecount+1))
                done
                return 0
        fi
        return 0
}

I will prepare a PR soon

@comio
Copy link
Contributor

comio commented Jan 30, 2018 •
edited

See PR #45

Please review the code with your contributions.

@kdave kdave added the RFC label Feb 19, 2018
@sten0
Copy link
Contributor

sten0 commented May 23, 2018 via email

@fcrozat
Copy link
Contributor

fcrozat commented May 24, 2018

openSUSE Leap 15 / SLE 15 (both SLES and SLED) are / will be shipping with systemd 234, systemd-ac-power is available there. There is no real point to supporting older Leap / SLE for this particular feature.

SLES and SLED 15 are similar regarding power handling. upower is available on both but will be installed by default only for graphical desktop installation. A pure text-only install of SLES will not install upower.

@comio
Copy link
Contributor

comio commented May 24, 2018 via email

@sten0
Copy link
Contributor

sten0 commented May 26, 2018 via email

@fcrozat
Copy link
Contributor

fcrozat commented Jun 1, 2018

AFAIK, there is no system-level method to handled UPS events. Both apupsd and nut are available on SLES but not installed by default.

@barak barak mentioned this issue Sep 24, 2018
Closed
@kdave kdave added this to the v0.5 milestone Sep 25, 2018
@GuillaumeSeren
Copy link

Hey there,
I have been using btrfsmaintenance on desktop/server and now I want to use it on my laptop too,
I have finally find this issue and the patches from @comio (Thank you).

I rebased against 0.4.1 and applyed the patches in my portage,
Ideally I would like the operation to wait to be on ac to start the patch,
this is done by the patch from @comio with a timer.

But I think there is an other part not really covered by this, like you are in ac and a task started (maybe even multiple task), but you don't notice it, and you unplugged the ac, I would like to pause the runnning process, and resume them when on back on ac, I know this seems not easy but btrfs support that so I think it could be great to have this.

@sten0
Copy link
Contributor

sten0 commented Mar 4, 2020 •
edited

@kdave, so, would you like me work on adding event-driven upower support, plus a config key (disabled by default). Also, would you like btrfsmaintenance to store it's state or unconditionally react to these upower events? The intent [edit: is] to DTRT when a laptop is unplugged, replugged, unplugged mid-operation, etc, and also to conserve power when a server goes to backup power (UPS).

@kdave kdave modified the milestones: v0.5, v0.5.1 Jul 30, 2020
@kdave kdave modified the milestones: v0.5.1, v0.5.2 Jul 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
RFC
Projects
None yet
Milestone
v0.5.2
Development

No branches or pull requests
5 participants
@fcrozat @comio @GuillaumeSeren @kdave @sten0