I enabled, rebooted and the service wasn’t enabled.
The /etc/default/btrfsmaintenance file was properly configured with the btrfs-defrag mountpoints, but timer didn’t enable automatically after reboot.
Edit: balancer.timer and scrub.timer were enabled automatically, I manually disabled them.
If you are on an SSD, I don’t think the performance loss is likely to be significant in a desktop workload unless you have a specialized use case. I think that monthly might be more frequently than needed in that scenario.
Yes. Best to be aware of where and when to use the defrag command.
Would you mind explaining a bit the command line executed in btrfs-defrag.sh from btrfsmaintenance
btrfs filesystem defrag -t 32m -f $BTRFS_VERBOSITY '{}' \
I read this:
btrfs filesystem defrag --help
usage: btrfs filesystem defragment [options] | [|…]Defragment a file or a directory -r defragment files recursively -c[zlib,lzo,zstd] compress the file while defragmenting -f flush data to disk immediately after defragmenting -s start defragment only from byte onward -l len defragment only up to len bytes -t size target extent size hint (default: 32M) -v deprecated, alias for global -v option Global options: -v|--verbose increase output verbosity
but I don’t know what the function of {} is.
Also further down in the same --help one can read:
Warning: most Linux kernels will break up the ref-links of COW data
(e.g., files copied with ‘cp --reflink’, snapshots) which may cause
considerable increase of space usage. See btrfs-filesystem(8) for
more information.
which confirms part of what @EOS has been referring to above.
You only quoted part of the command. The full command is:
find "$P" -xdev -size "$BTRFS_DEFRAG_MIN_SIZE" -type f \
-exec btrfs filesystem defrag -t 32m -f $BTRFS_VERBOSITY '{}' \;
The {} is part of the find syntax. It is replaced by each result returned by find.
Sorry about that!
My bad and let’s admit it my ignorance 
Thank you!
Saves a lot of headaches for me 
Just curious, If I install yay -S btrfsmaintenance from the AUR and do a reboot, is there anything I have to do or are default timers automatically set to take care of like 99% of use case maintenance? I know openSUSE uses btrfsmaintenance by default as well, but I don’t know the exact values they have set. I don’t have any special use cases myself, but I have wondered if I ever really need to do anything maintenance wise with like defragging, balancing, and/or scrubbing? It looks like this package could handle all of that with timers so my hands are wiped clean of any manual maintenance if I’m understanding correctly, which I probably don’t 
If I am remembering correctly, the timers for balance and scrub are enabled by default at weekly and monthly respectively.
If you use Btrfs Assistant you can see the settings there once it is installed.
so if I install btrfsmaintenance, reboot, and then install your btrfs assistant, the assistant will read the values btrfsmaintenance has set?
Yes, except there is no need to reboot.
If you don’t already use btrfs assistant, you can just read the config file.
Hmm, if I don’t have cronie installed currently will the btrffsmaintenance script timers still run or do I need to install cronie as well for this to work? Looking over the GitHub now for where the config file is.
No, you don’t need a cron. It can use systemd timers
Systemd timers
There’s a set of timer units that run the respective task script. The periods are configured in the
/etc/sysconfig/btrfsmaintenancefile as well. The timers have to be installed using a similar way as cron. Please note that the ‘.timer’ and respective '.service’ files have to be installed so the timers work properly.
Checking sudo nano /etc/sysconfig/btrfsmaintenanc shows the directory/file does not exist so the systemd timers aren’t set by default you think?
On Arch the file is at /etc/default/btrfsmaintenance
/etc/default/btrfsmaintenanceon Debian and derivatives
Yeah it was right there, I was stuck on /usr/share/btrfsmaintenance and /etc/sysconfig/btrfsmaintenance before I saw that on the list too, you were just way faster than me , thanks for pointing out the painfully obvious to the oblivious 
sudo nano /etc/default/btrfsmaintenance
## Path: System/File systems/btrfs
## Type: string(none,stdout,journal,syslog)
## Default: "stdout"
#
# Output target for messages. Journal and syslog messages are tagged by the task name like
# 'btrfs-scrub' etc.
BTRFS_LOG_OUTPUT="stdout"
## Path: System/File systems/btrfs
## Type: string
## Default: ""
#
# Run periodic defrag on selected paths. The files from a given path do not
# cross mount points or other subvolumes/snapshots. If you want to defragment
# nested subvolumes, all have to be listed in this variable.
# (Colon separated paths)
BTRFS_DEFRAG_PATHS=""
## Path: System/File systems/btrfs
## Type: string(none,daily,weekly,monthly)
## Default: "none"
## ServiceRestart: btrfsmaintenance-refresh
#
# Frequency of defrag.
BTRFS_DEFRAG_PERIOD="none"
## Path: System/File systems/btrfs
## Type: string
## Default: "+1M"
#
# Minimal file size to consider for defragmentation
BTRFS_DEFRAG_MIN_SIZE="+1M"
## Path: System/File systems/btrfs
## Type: string
## Default: "/"
#
# Which mountpoints/filesystems to balance periodically. This may reclaim unused
# portions of the filesystem and make the rest more compact.
# (Colon separated paths)
# The special word/mountpoint "auto" will evaluate all mounted btrfs
# filesystems
BTRFS_BALANCE_MOUNTPOINTS="/"
## Path: System/File systems/btrfs
## Type: string(none,daily,weekly,monthly)
## Default: "weekly"
## ServiceRestart: btrfsmaintenance-refresh
#
# Frequency of periodic balance.
#
# The frequency may be specified using one of the listed values or
# in the format documented in the "Calendar Events" section of systemd.time(7),
# if available.
BTRFS_BALANCE_PERIOD="weekly"
## Path: System/File systems/btrfs
## Type: string
## Default: "5 10"
#
# The usage percent for balancing data block groups.
#
# Note: default values should not disturb normal work but may not reclaim
# enough block groups. If you observe that, add higher values but beware that
# this will increase IO load on the system.
BTRFS_BALANCE_DUSAGE="5 10"
## Path: System/File systems/btrfs
## Type: string
## Default: "5"
#
# The usage percent for balancing metadata block groups. The values are also
# used in case the filesystem has mixed blockgroups.
#
# Note: default values should not disturb normal work but may not reclaim
# enough block groups. If you observe that, add higher values but beware that
# this will increase IO load on the system.
BTRFS_BALANCE_MUSAGE="5"
## Path: System/File systems/btrfs
## Type: string
## Default: "/"
#
# Which mountpoints/filesystems to scrub periodically.
# (Colon separated paths)
# The special word/mountpoint "auto" will evaluate all mounted btrfs
# filesystems
BTRFS_SCRUB_MOUNTPOINTS="/"
## Path: System/File systems/btrfs
## Type: string(none,weekly,monthly)
## Default: "monthly"
## ServiceRestart: btrfsmaintenance-refresh
#
# Frequency of periodic scrub.
#
# The frequency may be specified using one of the listed values or
# in the format documented in the "Calendar Events" section of systemd.time(7),
# if available.
BTRFS_SCRUB_PERIOD="monthly"
## Path: System/File systems/btrfs
## Type: string(idle,normal)
## Default: "idle"
#
# Priority of IO at which the scrub process will run. Idle should not degrade
# performance but may take longer to finish.
BTRFS_SCRUB_PRIORITY="idle"
## Path: System/File systems/btrfs
## Type: boolean
## Default: "false"
#
# Do read-only scrub and don't try to repair anything.
BTRFS_SCRUB_READ_ONLY="false"
## Path: System/File systems/btrfs
## Description: Configuration for periodic fstrim
## Type: string(none,daily,weekly,monthly)
## Default: "none"
## ServiceRestart: btrfsmaintenance-refresh
#
# 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'.
#
# The frequency may be specified using one of the listed values or
# in the format documented in the "Calendar Events" section of systemd.time(7),
# if available.
BTRFS_TRIM_PERIOD="none"
## Path: System/File systems/btrfs
## Description: Configuration for periodic fstrim - mountpoints
## Type: string
## Default: "/"
#
# Which mountpoints/filesystems to trim periodically.
# (Colon separated paths)
# The special word/mountpoint "auto" will evaluate all mounted btrfs
# filesystems
BTRFS_TRIM_MOUNTPOINTS="/"
## Path: System/File systems/btrfs
## Description: Configuration to allow concurrent jobs
## Type: boolean
## Default: "false"
#
# These maintenance tasks may compete for resources with each other, blocking
# out other tasks from using the file systems. This option will force
# these jobs to run in FIFO order when scheduled at overlapping times. This
# may include tasks scheduled to run when a system resumes or boots when
# the timer for these tasks(s) elapsed while the system was suspended
# or powered off.
BTRFS_ALLOW_CONCURRENCY="false"
Looks by default it does/doesn’t do some of the following:
no defrag: BTRFS_DEFRAG_PATHS="" BTRFS_DEFRAG_PERIOD="none"
balance “/” (where / is everything I think) weekly: BTRFS_BALANCE_PERIOD="weekly"
scrub monthly: BTRFS_SCRUB_PERIOD="monthly"
TRIM: BTRFS_TRIM_PERIOD="none"
So basically this script as defaults will balance weekly and scrub monthly, which from my understanding is generally the only maintenance the average user will need with btrfs, or do I need to add anything else? I’m just a simpler user 
If your disk is an SSD, then that should be fine.
You should also be doing a trim if it is an SSD but I think it is better to do that with the fstrim.timer than with Btrfs Assistant.
Don’t worry, way ahead of you, that’s one of my post install tasks. But I’ll be sure to add btrfsmaintenance to my list too now.
Enable SSD Trim (frees unused blocks of data once a week, good for SSD health) for SSD drives:
sudo systemctl start fstrim.timer
sudo systemctl enable fstrim.timer
systemctl status fstrim.timer
I do wonder though, the last btrfsmaintenance commit was from almost 2 years ago. Usually I’m a bit wary to use things not updated in 2 or more years, just as a general practice, there’s always exceptions to the rule of course. I guess if the maintenance script is more or less feature complete and bug free, there’s nothing to update/fix?
It is just shell scripts which call btrfs commands. As long as the syntax for the btrfs commands doesn’t change, it shouldn’t need much in the way of updates.
Yeah that’s pretty much what I figured, but it never hurts to have someone way more knowledgeable confirm it of course. Thanks bunches for the help and assistance, 1-888-dial-dalto for all your EndeavourOS Tech Support needs 