Bug#813901: ITP: btrfsmaintenance -- Btrfs maintenance toolbox
> 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.
Reply to: