Is the Btrfs mount option "autodefrag" snapshot-aware?

thePhysicist8 · 2016-01-27 20:44:52

I understand that the Btrfs devs removed the snapshot-aware feature of the btrfs filesystem defragment command in Linux 3.14, which means that all copy-on-write links will be broken and snapshots will contribute to used disk space once the defrag completes. Does this apply to the autodefrag mount option also? Does using it effectively imply the nodatacow option? I haven't found any definitive answers either way.

Soukyuu · 2016-01-27 21:38:21

It most certainly doesn't imply nodatacow, I'd notice that. I don't think it's snapshot-aware, but the impact should be rather low considering it only touches a file if it passes a certain fragment threshold. That will only result in that single file taking up HDD space of all of its snapshots.
If no one has any definite information, your best be would be probably asking on the btrfs irc channel.

nstgc · 2016-01-28 14:21:03

If my understanding of the mount option is correct, it doesn't need to be snapshot aware. What it believe it is doing is defragmenting a file that hasn't been written yet. Say you have a file that is being written to frequently. You have pieces being written to all over the place. What this option does, if I'm correct, is to defragment all those pieces before they are written to disk.

Soukyuu · 2016-01-28 16:53:42

If that was the case, wouldn't re-writing the file effectively mean breaking the reflinks? The reflinks only exist on the disk itself, as far as I understand it, and every time you change a part of a file, that part is rewritten as a standalone copy. The rest of the file remains reflinked for any of the other copies.

nstgc · 2016-01-29 15:48:14

Hmm? No. Btrfs never overwrites a file. Well, barring any bugs, it shouldn't.

Say that without autodegrag, btrfs would write data to disk sectors A, C, and E. Well, that would be fragmented. So while the writes are pending, in memory, btrfs optimizes the writes so to instead write them to A, B, C. Nothing is being rewritten, rather, the memory is being allocated differently.

Soukyuu · 2016-01-29 21:14:24

I didn't mean that it is being overwritten, but relocated. Assuming you have a file in nodes A, C, G, F and D, writing the next fragment in H would trigger the internal "too fragmented" event, causing the whole file to be defragmented to nodes H-N, thus breaking links.

What you describe is not defragmenting, it's smart file allocation. That works quite well with modern file systems, at least as long as there is enough free space. For example, as far as I know, there is no "need" to defragment ext4 because it always tries to allocated files as far apart from each other as possible, thus minimizing fragmentation.

However, once the space starts running out, there is a higher chance that files will become fragmented. A "defragmentation" is the process of reducing the number of those fragments of a file, which means the file has to already be fragmented on disk.
The only difference between defrag and autodefrag is that autodefrag defragments per file, not per filesystem.

edit: I just went ahead and asked the question on the btrfs irc channel, read the replies here.

Last edited by Soukyuu (2016-01-29 21:24:48)

Arch Linux

#1 2016-01-27 20:44:52

Is the Btrfs mount option "autodefrag" snapshot-aware?

#2 2016-01-27 21:38:21

Re: Is the Btrfs mount option "autodefrag" snapshot-aware?

#3 2016-01-28 14:21:03

Re: Is the Btrfs mount option "autodefrag" snapshot-aware?

#4 2016-01-28 16:53:42

Re: Is the Btrfs mount option "autodefrag" snapshot-aware?

#5 2016-01-29 15:48:14

Re: Is the Btrfs mount option "autodefrag" snapshot-aware?

#6 2016-01-29 21:14:24

Re: Is the Btrfs mount option "autodefrag" snapshot-aware?

Board footer