kdave
commented
4 years ago In 0.5 the systemd.timer calendar time format can be used to set a specific time of the tasks, also the defaults have been reduced so the long io stalls and performance drop should not happen. Closing.
If there were a global lock that kept new btrfsmaintenance tasks from running, thus preventing them from stepping on each others' toes (see issue #15 and discussion therein), this could be used for another purpose. It is a pain to have btrfs scrub or balance start while I'm trying to use my desktop computer. I'd rather these do their work when I'm not trying to do mine! How about another task, called "btrfs-blackout" or something like that, which would do nothing but hold a btrfsmaintenance lock file during specified periods. E.g., Mon-Fri 08:00-16:00 would be nice on my work desktop, so my computer doesn't decide it has more important things to do than respond to my inputs while I'm in my office trying to get work done.
This could also be used as a place to centralize policy decisions about this: grab the lock when on battery power, for example, or grab the lock for 10 minutes after power on to give other things time to settle down, or grab it if there has been interactive usage within the last few minutes, or grab it if the load factor is high.
(I know these tasks are supposed to be running at a very low priority and not interfere with anything else. But I suspect they evict things from the buffer cache, and also somehow manage to hog the disk anyway. This is a btrfs performance issue, and ideally would ultimately be addressed there. But in the meantime, it would be best if my desktop did not become unusable for an hour following its first reboot after two weeks turned off. It's even worse if my laptop goes south during a lecture to 350 students.)
This also relates to a few other issues: #15, #42, #53.