Quoting Chris Murphy <li...@colorremedies.com>:
On Thu, Sep 12, 2019 at 1:18 PM <webmas...@zedlx.com> wrote:
It is normal and common for defrag operation to use some disk space
while it is running. I estimate that a reasonable limit would be to
use up to 1% of total partition size. So, if a partition size is 100
GB, the defrag can use 1 GB. Lets call this "defrag operation space".
The simplest case of a file with no shared extents, the minimum free
space should be set to the potential maximum rewrite of the file, i.e.
100% of the file size. Since Btrfs is COW, the entire operation must
succeed or fail, no possibility of an ambiguous in between state, and
this does apply to defragment.
So if you're defragging a 10GiB file, you need 10GiB minimum free
space to COW those extents to a new, mostly contiguous, set of exents,
False.
You can defragment just 1 GB of that file, and then just write out to
disk (in new extents) an entire new version of b-trees.
Of course, you don't really need to do all that, as usually only a
small part of the b-trees need to be updated.
The only problem that there can arise is if the original file is
entirely one 10 GB extent. In that case, that extent should be split
into smaller parts. If btrfs cannot do that splitting, mostly (but not
entirely) in-place, than it is a fundamentally flawed design, but I
reckon that is not the case. You would have to be really stupid to
design a filesystem that way, if it is even possible to design a
filesystem with such property.
