Re: defragmenting best practice?

[Dave <davestechshop@gmail.com>]

On Thu, Nov 2, 2017 at 5:16 PM, Kai Krakow <hurikhan77@gmail.com> wrote:

>
> You may want to try btrfs autodefrag mount option and see if it
> improves things (tho, the effect may take days or weeks to apply if you
> didn't enable it right from the creation of the filesystem).
>
> Also, autodefrag will probably unshare reflinks on your snapshots. You
> may be able to use bees[1] to work against this effect. Its interaction
> with autodefrag is not well tested but it works fine for me. Also, bees
> is able to reduce some of the fragmentation during deduplication
> because it will rewrite extents back into bigger chunks (but only for
> duplicated data).
>
> [1]: https://github.com/Zygo/bees

I will look into bees. And yes, I plan to try autodefrag. (I already
have it enabled now.) However, I need to understand something about
how btrfs send-receive works in regard to reflinks and fragmentation.

Say I have 2 snapshots on my live volume. The earlier one of them has
already been sent to another block device by btrfs send-receive (full
backup). Now defrag runs on the live volume and breaks some percentage
of the reflinks. At this point I do an incremental btrfs send-receive
using "-p" (or "-c") with the diff going to the same other block
device where the prior snapshot was already sent.

Will reflinks be "made whole" (restored) on the receiving block
device? Or is the state of the source volume replicated so closely
that reflink status is the same on the target?

Also, is fragmentation reduced on the receiving block device?

My expectation is that fragmentation would be reduced and duplication
would be reduced too. In other words, does send-receive result in
defragmentation and deduplication too?