http://bugzilla.suse.com/show_bug.cgi?id=1124823
http://bugzilla.suse.com/show_bug.cgi?id=1124823#c20
--- Comment #20 from Jean Delvare
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. -- You are receiving this mail because: You are on the CC list for the bug.