Comment # 20 on bug 1124823 from Jean Delvare

(In reply to ravas mi from comment #19)
> I consider a weekly popup less intrusive than the system automatically
> starting a drive maintenance operation at boot or when I'm using the
> computer or wanting to shutdown the computer.

No maintenance job should slow down the boot process. At the earliest,
maintenance should start after boot has fully completed, but it could make
sense to delay it by 10 minutes or so, to give a user in a hurry the time to
log in and run whatever application they need. After that the disk is less used
so maintenance should be transparent.

Maintenance at runtime is certainly the least of evils, although it should be
avoided when laptop is running on battery. It still might have to be done in
this case if the user always runs the laptop on battery and loads the battery
with laptop off.

Maintenance at stop time makes sense in certain cases (fixed desktop machine,
if you power it down you must be done with it for a while so it doesn't matter
if power down takes extra time) but could be unacceptable in other cases
(laptop which you power down because you must move somewhere else - whether you
were on battery or not).

At the end of the day there is no single perfect strategy because there is no
way to anticipate what the user is going to do in the next 5 minutes. Still, we
do not want to bother the user at installation time, and we don't want to
bother the user at runtime by default either. It certainly makes sense to make
the strategy configurable, including an interactive option if some people
prefer that, just it shouldn't be the default.

> If the automated approach
> interferes with any of that (and it does), without even informing me of what
> is happening, then it's definitely not "transparent".
> 
> The problem isn't just related to btrfs: "fstrim.timer" is not specific to
> btrfs.

I don't know how heavy btrfs maintenance is on the disks nor how long it is
expected to take, but in my experience fstrim is pretty fast, we are talking
just a few seconds per drive so it should not really matter that much when it
is being run. In both cases we need the maintenance task to have lower I/O
priority than user-triggered I/O so that it is as transparent as possible.

> > FS maintenance (if really needed) should be called when the system is
> > actually idle.

In theory this is fine and even obvious. In practice, how do you determine
that, and does systemd timers even support that notion?

It will never be perfect anyway... You can check the load now, but you can't
anticipate what it will be in the immediate future. Also you need to ensure
that the maintenance will happen once in a while even if the system is under
load all the time.