> Is trim different from fstrim (util-linux)? It also ships systemd timer > configuration as an example, maybe we could enable those by default?
The trim in this case uses the 'fstrim' binary but is performend only on the configured mountpoints (BTRFS_TRIM_MOUNTPOINTS). The fstrim.timer service is orthogonal. The reason for separate ways to do the trim: * when btrfs is used, the configuration is in one place * not everybody has btrfs on the system but wants to run the trim periodically, installing a "btrfs" package would look strange > Is manual defrag a thing one should do today? What's the advantage/what > are the drawbacks over autodefrag (and making that the default)? The defrag is optional and only for completeness of the potentially periodic tasks. Default configuration is a no-op. Examples for such files is the /var/lib/rpm (or equivalent in case of debian). The expected benefit is for files with write-seldom/read-often files, eg. typically the package database files. If the files access pattern is "database", ie. random overwrites, the defragmentation will make the files (more) contiguous and pays the price once. Future reads will be fster, compared to reading the fragmented files. In the above case, the defragmentation is done 'when needed' and can be fine tuned (eg. setting a large target extent size, in range of megabytes). The 'autodefrag' affects the whole filesystem and adds a read latency. Due to the real-time nature of the auto-defragmentation, the neighboring extents do not reach further than a few tens of kilobytes. Thus the effects of autodefrag are smaller compared to the manual defragmentation, if we take the package database files as an example.
