Fresh Leap 15.3 transactional-server installation btrfs-balance.sh errors

Hi all,

New Opensuse user here, I decided to give a go to Leap 15.3 with the transactional-server role, making the / filesystem readonly. I noticed that once a day, at midnight, I get a bunch of errors such as:

While I could probably just ignore those errors, I don’t think they should be in here at all in the first place if the OS is properly designed. btrfs-scrub/btrfs-balance most likely both need some modification (or should otherwise be disabled if they can’t do their job).

btrfs-scrub/btrfs-balance do their job perfectly on reliable hardware. No modifications needed.

If you set root as read only then maintenance and many other things can not be done since writing to / is common.

Maybe so, they should still be edited to not produce errors. It tries to do something it can’t do.

It’s a fresh install and a default option in the installer (the transactional-server role). I would expect the official Leap 15.3 distro to not be shipped out of the box with errors such as this one.

Interesting, according to this, read-only is wanted indeed plus the use of btrfs and snapper:
https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-install.html#sec-yast-install-system-role
https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/
Admittedly, there is no hint to the maintenance routinely carried out by btrfs unless it’s mentioned deeper in the docs somewhere. So, if you really want / need that feature, scheduled scrub/balance should probably better be switched off. The others know better than me how to do this. Some manual maintenance from time to time might be advisable, though.

Edit: Settings should be in: /etc/sysconfig/btrfsmaintenance

I’d say

BTRFS_BALANCE_PERIOD="none"

BTRFS_SCRUB_PERIOD="none"

Should do the job.

There is an option for read-only scrub:

# Do read-only scrub and don't try to repair anything.
BTRFS_SCRUB_READ_ONLY="false"

It will probably provide some info what would / should have been done.

Trimming might better be switched off, too:

# Frequency of periodic trim. Off by default so it does not collide with
# fstrim.timer . If you do not use the timer, turn it on here. The recommended
# period is 'weekly'.
BTRFS_TRIM_PERIOD="none"

Ah, there was a problem with the links. Here’s the missing one:
https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/

Why isn’t this set like this by default when transactional-server role is selecting during install? Sounds like a bug to me.

Some more insights after tests.


vm-opensuse:~ # cat /usr/lib/systemd/system/btrfs-scrub.timer
[Unit]
Description=Scrub btrfs filesystem, verify block checksums
Documentation=man:btrfs-scrub


[Timer]
OnCalendar=monthly
AccuracySec=1h
Persistent=true


[Install]
WantedBy=timers.target

This is monthly. If I start it, I do get the error:

vm-opensuse:~ # systemctl start btrfs-scrub
vm-opensuse:~ # systemctl status btrfs-scrub
● btrfs-scrub.service - Scrub btrfs filesystem, verify block checksums
     Loaded: loaded (/usr/lib/systemd/system/btrfs-scrub.service; static)
     Active: inactive (dead) since Wed 2021-12-01 18:24:28 EST; 12s ago
TriggeredBy: ● btrfs-scrub.timer
       Docs: man:fstrim
    Process: 27067 ExecStart=/usr/share/btrfsmaintenance/btrfs-scrub.sh (code=exited, status=0/SUCCESS)
   Main PID: 27067 (code=exited, status=0/SUCCESS)


Dec 01 18:24:28 vm-opensuse systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]: Running scrub on /
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]: ERROR: scrubbing / failed for device id 1: ret=-1, errno=30 (Read-only>
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]: scrub device /dev/vda2 (id 1) canceled
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]:         scrub started at Wed Dec  1 18:24:28 2021 and was aborted afte>
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]:         total bytes scrubbed: 0.00B with 0 errors
Dec 01 18:24:28 vm-opensuse btrfs-scrub.sh[27074]: Scrub cancelled at /
Dec 01 18:24:28 vm-opensuse systemd[1]: btrfs-scrub.service: Succeeded.

After changing BTRFS_SCRUB_READ_ONLY to “true” however, no more error:


vm-opensuse:~ # systemctl start btrfs-scrub
vm-opensuse:~ # systemctl status btrfs-scrub
● btrfs-scrub.service - Scrub btrfs filesystem, verify block checksums
     Loaded: loaded (/usr/lib/systemd/system/btrfs-scrub.service; static)
     Active: inactive (dead) since Wed 2021-12-01 18:25:00 EST; 2min 37s ago
TriggeredBy: ● btrfs-scrub.timer
       Docs: man:fstrim
    Process: 23216 ExecStart=/usr/share/btrfsmaintenance/btrfs-scrub.sh (code=exited, status=0/SUCCESS)
   Main PID: 23216 (code=exited, status=0/SUCCESS)


Dec 01 18:24:57 vm-opensuse systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Dec 01 18:24:57 vm-opensuse btrfs-scrub.sh[23223]: Running scrub on /
Dec 01 18:25:00 vm-opensuse btrfs-scrub.sh[23223]: scrub device /dev/vda2 (id 1) done
Dec 01 18:25:00 vm-opensuse btrfs-scrub.sh[23223]:         scrub started at Wed Dec  1 18:24:57 2021 and finished after>
Dec 01 18:25:00 vm-opensuse btrfs-scrub.sh[23223]:         total bytes scrubbed: 7.21GiB with 0 errors
Dec 01 18:25:00 vm-opensuse systemd[1]: btrfs-scrub.service: Succeeded.

So this fixes btrfs-scrub while still keeping it functionnal to check for any weird checksums (from the doc I would get an error code 3 if anything weird was found). As for btrfs-maintenance, I’m honestly debating whether I should disable it or just remove it like suggested in the official doc here:
https://en.opensuse.org/SDB:Disable_btrfsmaintenance

Seems like this one can’t really be used with a read-only FS at all.

How system will use swap? How user will write files?

The OP in his first post said:

making the / filesystem readonly

So the answer to your first question is: as long as there is not file swap specified in the root partition (which not many people have), swapping can take place in swap partitions and/or swap files in other file systems.

And the answer to the second question will be that he most probably has a separate file system for /home (and maybe other file systems for user usage) that are of course not mounted read-only.

And if this separate /home or other partition has BTRFS FS, and user disables or uninstalls tools for BTRFS, then they will be unmanageable…
I’m talking about question in the first post: it is feature, not a bug.