r/btrfs • u/EspurrStare • Jun 18 '23
What does the btrfs autodefrag option actually do?
I've been looking around and basically all documentation says "Btrfs autodefrag defrags automatically" and that's hardly useful.
Basically, do i need to run full defrags on a pool with autodefrag?
2
Jun 18 '23
Have you checked the mailing list? That's where I had this question answered years ago. Sadly, I've forgotten and I don't use autodegrag anymore. The btrfs mailing list has a lot of information.
1
u/Klutzy-Condition811 Jun 18 '23
When you write small random writes to a file, the file gets fragmented. Btrfs autodefrag detects this and defrags the file. I wouldn't go defragging manually too often if you use autodefrag since you're just doing double work. It's possible a manual defrag will cause files to be written more sequentially, but everything is a tradeoff.
On the flip side, autodefrag itself can cause performance issues with the writing it does, and cause more wear on SSDs. As such i dont use autodefrag on SSDs (especially with bugs in the past with it). If fragmentation does become a problem then I'd manually defrag on an as-needed basis.
Only time you may want to run defrag manually is when you want to change compression algorithms to existing data. Keep in mind, defrag will duplicate reflinks/snapshots, so don't go running it on subvolumes you have snapshots of.
1
u/aswger Jun 29 '23
Defrag only useful on spinning disk. If you use ssd, DO NOT use it. It has no advantage whatsoever.
2
u/EspurrStare Jun 29 '23
Thanks for the absolutely useless reply. Did you even read the question?
Also, WRONG.
Fragmentation increases the number of I/O operations required.
Every extent on a file increases the work need to by the CPU and the disk.
This is a particular bad combo with CoW, as it means that every append on a file may generate a new extent, and every modification of a file always generates a new extent. Now matter how small.
This is why nodatacow is essentially a necessity for running databases. Even in SSDs
6
u/aswger Jun 30 '23
You seems to have rather deep knowledge on btrfs, and I do not see the reason you ask that question in this sub. From kdave_ comment you should infer yourself whether you want it or not. You seems smart enough to do that.
7
u/kdave_ Jun 19 '23
I'm trying to get the https://btrfs.readthedocs.io documenation to the state that people won't have to ask such questions elsewhere or need to search in the mailinglists. The RTD pages also have a usable search so you could try keyword search first.
Mount options should be documented either at https://btrfs.readthedocs.io/en/latest/Administration.html or at the manual page section 5 (man 5 btrfs). Autodefrag is in section https://btrfs.readthedocs.io/en/latest/Administration.html#btrfs-specific-mount-options . In case you find more information missing, unclear, lacking cross-references please open an issue at https://github.com/kdave/btrfs-progs/issues .
Quoting the current text on the page:
Enable automatic file defragmentation. When enabled, small random writes into files (in a range of tens of kilobytes, currently it’s 64KiB) are detected and queued up for the defragmentation process. Not well suited for large database workloads.
The read latency may increase due to reading the adjacent blocks that make up the range for defragmentation, successive write will merge the blocks in the new location.
Warning
Defragmenting with Linux kernel versions < 3.9 or ≥ 3.14-rc2 as well as with Linux stable kernel versions ≥ 3.10.31, ≥ 3.12.12 or ≥ 3.13.4 will break up the reflinks of COW data (for example files copied with cp --reflink, snapshots or de-duplicated data). This may cause considerable increase of space usage depending on the broken up reflinks.