Re: [PATCH 0/2] btrfs: defrag: better lone extent handling

[Christoph Anton Mitterer <calestyo@scientia.org>]

Hey.

From an admin PoV, I wonder whether this (i.e. doing it via defrag) is
the (only) desired approach to this problem.


defrag always sounds like a manual intervention on a degrading
filesystem, which for an admin is always rater undesirable than
desirable.
(questions like: How often needs on to run it? What are the best
settings? Does it impact the regular system IO? ...)


Your patches to btrfs-progs, would that allow one to defrag *only* the
extents with the cut-off?
I mean from an admin-PoV I may want to fix that - but not defrag all
other files, which may involve quite some reading/writing?


Would it technically even be possible, to fix (= shrink by rewriting)
the extent right at the time when the userspace truncates it?
I mean has btrfs even a chance to notice it at that point ("oops, we've
just wasted n MB, shall we do something about it right, or wait for the
user to manually defrag?").

Feels a bit like a mount option where one could say if a truncate
causes more than n bytes to be lost, re-write instantaneously.

*If* that would even be possible, it doesn't mean that the defrag way
couldn't be beneficial, too.
Some people may rather want to waste the space first, and only clean up
later, when IO is less busy.



Cheers,
Chris.