Re: de-duplicating +C files

[Adam Borowski <kilobyte@angband.pl>]

On Wed, Oct 07, 2020 at 02:29:34AM -0400, Eric Levy wrote:
> Recently a discussion [1] began about the desirability or risk of
> applying a de-duplication operation on files with a C (no-CoW)
> attribute set. The controversy rests largely on the observation that
> calls to Btrfs currently fail for de-duplication between two files if
> exactly one has the attribute set, but succeed in other cases, even in
> which both have the attribute set. It may seem more natural that
> success depends on neither file having the attribute set.

Why?  It's just that the flag is misnamed, it should be "overwrite in-place"
as it doesn't block CoW in any way.  It works like most uses of the word
"CoW" elsewhere: a page is CoWed once whenever it's written to when its
refcount is more than 1.

You can already reflink by snapshotting the subvolume that contains your
file, thus there's no point in blocking explicit deduplication.

The behaviour when trying to dedupe a -C extent with a +C one is less clear.
I'd argue to either:
 * prefer the -C copy, or
 * refuse (current state)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄⠀⠀⠀⠀ sky.  Your cat demands food.  The priority should be obvious...