(In reply to Axel Braun from comment #0)
> Install TW using ext4 or anything, you notice that btrfsmaintenace-refresh
> is started, although it is useless.
FYI: This was disussed almost one year ago in the opensuse-factory mailing list: https://lists.opensuse.org/opensuse-factory/2018-03/msg00294.html

(In reply to Frank Kruger from comment #1)
> (In reply to Axel Braun from comment #0)
> > Install TW using ext4 or anything, you notice that btrfsmaintenace-refresh
> > is started, although it is useless.
> FYI: This was disussed almost one year ago in the opensuse-factory mailing
> list: https://lists.opensuse.org/opensuse-factory/2018-03/msg00294.html

Obviously without result in terms of system (pre-)settings

I still see btrfsmaintenance-refresh.service taking around 15 sec. at start in Leap 15.1beta and TW20190417 with ext4.

Same problem here, btrfsmaintenance-refresh.service takes 32 seconds at boot, every time. The system does not have any btrfs partition.

As a user, I don't want to waste boot time for a service related to a filesystem type I do not use. btrfsmaintenance-refresh.service should not be enabled when there is no btrfs filesystem. Ideally the whole set of btrfs utilities should not even be installed in that case.

Is this something which should be done by the yast2 partitioner/installer?

I use btrfs but dislike the system automatically starting heavy disk operations when I haven't asked for it to. Before I understood what was happening I was disturbed by the weekly slow boot and solid disk activity indicator light, since there was nothing informing me of what was happening. I've disabled it and run the scripts manually. 

https://en.opensuse.org/SDB:Disable_btrfsmaintenance

If a btrfs partition exists, I'd have the installer ask
"Would you like to activate a scheduled disk maintenance service?"

I'd also present the defaults and allow the user to choose how often each script is run (i.e. none, daily, weekly, monthly).

The help menu can tell us why running trim, balance, and scrub are desirable.

See also bug #1145179.

yast2-maintainers is a mailing list; setting that to NEEDINFO might bury a bug for a considerable time.

[shundhammer @ g12] ~ % rpm -qf /usr/lib/systemd/system/btrfsmaintenance-refresh.service
btrfsmaintenance-0.4.2-3.1.noarch

[shundhammer @ g12] ~ % cat /usr/lib/systemd/system/btrfsmaintenance-refresh.service
    
[Unit]
Description=Update cron periods from /etc/sysconfig/btrfsmaintenance
After=local-fs.target

[Service]
ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh systemd-timer
Type=oneshot

[Install]
Also=btrfsmaintenance-refresh.path
WantedBy=multi-user.target



I am not (yet) sure who and why this package was added to the set of packages to the install. But one way or the other, the service should behave well even if no applicable filesystems are present on the system; the package might be installed by accident, by a user unsure of the consequences, or by a lot of other package dependencies.

Systemd handles mounting the filesystems, so it should also know which filesystem types are involved. I don't know if there are suitable conditions available that could be used in a .service file to make this happen.

But also the underlying tools that are called in that cron job should be finished quickly if there is no Btrfs to take care of. I can completely understand the wish to get this over with quickly if there is no Btrfs; 32 seconds delay sounds excessive.

YaST (more precisely: yast-storage-ng) installs filesystem tools only on demand if they are needed, i.e. if that type of filesystem is actually present on the system (or if the user wishes to create a filesystem of that type). 

But that's a very short list, and the "btrfsmaintenance" package is not among them:

  https://github.com/yast/yast-storage-ng/blob/master/src/lib/y2storage/used_storage_features.rb#L52

For Btrfs, it will only add "btrfsprogs" and "e2fsprogs" (for the "lsattr" and the "chattr" commands) to the set of packages to install.

So I guess that this "btrfsmaintenance" package comes in via one of the software patterns.

*** Bug 1145179 has been marked as a duplicate of this bug. ***

I found that I also have that package installed (I had a Btrfs root filesystem for a while), but I can uninstall it without any warning or dependency problems.

I have an up-to-date Tumbleweed, and it looks like package "btrfsmaintenance" is recommended by package "btrfsprogs" which is recommended by pattern "patterns-base-base":


[shundhammer @ g12] ~ % rpm -q --whatrecommends btrfsprogs
guestfs-data-1.38.0-8.1.x86_64
gparted-1.0.0-3.1.x86_64
patterns-base-base-20190612-1.1.x86_64

[shundhammer @ g12] ~ % rpm -q --whatrecommends btrfsmaintenance
btrfsprogs-5.2.1-1.1.x86_64

[shundhammer @ g12] ~ % rpm -q --whatrecommends btrfsprogs      
guestfs-data-1.38.0-8.1.x86_64
gparted-1.0.0-3.1.x86_64
patterns-base-base-20190612-1.1.x86_64


So that package gets dragged in via "recommends" dependencies no matter what the YaST installer is doing (the base pattern will always be installed).

This explains how you got that package; still, it should not misbehave even if it was installed for no good reason.

(In reply to ravas mi from comment #5)
> If a btrfs partition exists, I'd have the installer ask
> "Would you like to activate a scheduled disk maintenance service?"

Sorry, no.

We strive to minimize the questions that most users can't be expected to answer.
If we as experts can't make a well-founded decision about this, how are the users expected to know? Based on what hard facts?

For those few experts who are in a position to know that, there is the config file /etc/sysconfig/btrfsmaintenance. Those values can also be changed with a GUI in the YaST sysconfig editor.

> "We strive to minimize the questions that most users can't be expected to answer."

Then I guess I would setup a popup to activate an hour after boot, and ask if it's a convenient time to perform disk maintenance. "It has been <X amount of time> since the disk maintenance script ran: Would you like to run it now?" With options to remind me in 1 hour, day, or week.

I'd also disable fstrim.timer and add the command to the new script.

The time WHEN such a question is asked does not change the problem that the vast majority of users is in no position to answer it.

It's a different question, and it's implied that it needs to happen -- just like a system update, or when my phone tells me it's been 7 days and it would be beneficial to reboot. Also, there would be a "Help" button that educates users.

Benefits include:

1. a consistent boot process
2. more awareness about what is happening
3. an opportunity to learn
4. it groups related services for easier configuration

(In reply to Stefan Hundhammer from comment #11)
> 
> [shundhammer @ g12] ~ % rpm -q --whatrecommends btrfsmaintenance
> btrfsprogs-5.2.1-1.1.x86_64
> 
> So that package gets dragged in via "recommends" dependencies no matter what
> the YaST installer is doing (the base pattern will always be installed).

There is a request to remove "recommends", https://bugzilla.suse.com/show_bug.cgi?id=1145650.

(In reply to ravas mi from comment #15)
> It's a different question, and it's implied that it needs to happen -- just
> like a system update, or when my phone tells me it's been 7 days and it
> would be beneficial to reboot.

There's nothing implied. The examples you give are nice illustrations of failed technology which takes user time instead of saving it. If your phone needs to be rebooted every 7 days to keep working properly, it's a bad phone. System updates should ideally be transparent to the user as well, the only case where users must be bothered is when a system update requires a reboot, but that's hopefully rare. I wish all other system updates would restart dependent applications automatically to switch to the new code ASAP without user interaction, but we are not there yet.

Anyway, filesystem maintenance should definitely be transparent to the user by default. Filesystems are here to serve the users, not to educate them. I'm with Stefan all the way here, no pop-up, no question asked, it must just do the right thing by default. If btrfs is so complex that there is no reasonable default then that means btrfs should not be the default filesystem to start with.

(In reply to ravas mi from comment #13)
> Then I guess I would setup a popup to activate an hour after boot, and ask
> if it's a convenient time to perform disk maintenance. "It has been <X
> amount of time> since the disk maintenance script ran: Would you like to run
> it now?" With options to remind me in 1 hour, day, or week.

There's no good place/time/way to display such a pop-up. Remember: Systems
are to serve, not to bother. For that reason, systems can run without any
user interaction (headless) or with several different display managers or
even without GUI, just with text-mode.

FS maintenance (if really needed) should be called when the system is actually 
idle. If it's idle, it often means there's nobody reading any pop-ups and
nobody can answer such question.

And BTW cron is ideally replaced with systemd-timer(s) https://www.freedesktop.org/software/systemd/man/systemd.timer.html

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. 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.

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

I'd prefer that to the current setup; although, it could still interfere with me wanting to shutdown the computer. So I guess if popups are out of the question, then the manual approach is the only thing I'm fully comfortable with. 

Thank you for your consideration.

(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.

(In reply to Stefan Hundhammer from comment #11)
> I have an up-to-date Tumbleweed, and it looks like package
> "btrfsmaintenance" is recommended by package "btrfsprogs" which is
> recommended by pattern "patterns-base-base":
> …
> So that package gets dragged in via "recommends" dependencies no matter what
> the YaST installer is doing (the base pattern will always be installed).

For the record: the base-pattern no longer recommends btrfsprogs since September 2019; so from that angle the issue has been addressed

For verification, I just installed a fresh TW VM (Snapshot 20200414) on an EXT4 root partition (Picked server role), and can confirm: btrfsprogs/btrfsmaintenance are not installed in this setup

> This explains how you got that package; still, it should not misbehave even
> if it was installed for no good reason.

That is imho a much more critical part to the issue: btrfsmaintenance should first check if there is sensible work to do anyway - no btrfs partition, quit early. I doubt this should take more than a fraction of a second.

(In reply to Dominique Leuenberger from comment #21)
> (In reply to Stefan Hundhammer from comment #11)
> > I have an up-to-date Tumbleweed, and it looks like package
> > "btrfsmaintenance" is recommended by package "btrfsprogs" which is
> > recommended by pattern "patterns-base-base":
> > …
> > So that package gets dragged in via "recommends" dependencies no matter what
> > the YaST installer is doing (the base pattern will always be installed).
> 
> For the record: the base-pattern no longer recommends btrfsprogs since
> September 2019; so from that angle the issue has been addressed

Thanks for the hint, I was not aware of this change. Removing btrfsprogs solves the issue, i.e., btrfsmaintenance is no longer recommended/installed automatically.

> That is imho a much more critical part to the issue: btrfsmaintenance should
> first check if there is sensible work to do anyway - no btrfs partition,
> quit early. I doubt this should take more than a fraction of a second.

By the way, on my dual core machine with ext4 it takes between 10 und 15 secs.

> That is imho a much more critical part to the issue: btrfsmaintenance should
> first check if there is sensible work to do anyway - no btrfs partition,
> quit early. I doubt this should take more than a fraction of a second.

There is a bug in btrfsmaintenance-refresh.path triggering btrfsmaintenance-refresh.service for no good reason. Fixing this bug btrfsmaintenance tools are quite unobtrusive without making further modifications: btrfsmaintenance-refresh.path starts up in no time and watches for changes of /etc/sysconfig/btrfsmaintenance which does not take a noticeable fraction of a second.

The fix is easy: Make *absolutely* sure btrfsmaintenance-refresh.path starts after local-fs.target is reached. Don't rely on defaults. They may change with versions of systemd, programmers changing their mind or making mistakes, phases of the moon ...

https://github.com/kdave/btrfsmaintenance/pull/79

(In reply to Karl Mistelberger from comment #23)
> > That is imho a much more critical part to the issue: btrfsmaintenance should
> > first check if there is sensible work to do anyway - no btrfs partition,
> > quit early. I doubt this should take more than a fraction of a second.
> 
> There is a bug in btrfsmaintenance-refresh.path triggering
> btrfsmaintenance-refresh.service for no good reason. Fixing this bug
> btrfsmaintenance tools are quite unobtrusive without making further
> modifications: btrfsmaintenance-refresh.path starts up in no time and
> watches for changes of /etc/sysconfig/btrfsmaintenance which does not take a
> noticeable fraction of a second.
> 
> The fix is easy: Make *absolutely* sure btrfsmaintenance-refresh.path starts
> after local-fs.target is reached. Don't rely on defaults. They may change
> with versions of systemd, programmers changing their mind or making
> mistakes, phases of the moon ...
> 
> https://github.com/kdave/btrfsmaintenance/pull/79

That looks really not difficult - maybe someone can test this patch in 
https://build.opensuse.org/package/show/home:DocB:branches:filesystems/btrfsmaintenance ?

Delete install section of btrfsmaintenance-refresh.service Vendor preset state is enabled, triggering erroneous activation. Deletion results in state static.

https://github.com/kdave/btrfsmaintenance/pull/81