On Wed, 2017-08-16 at 09:53 -0400, Austin S. Hemmelgarn wrote:

Go try BTRFS on top of dm-integrity, or on a 
system with T10-DIF or T13-EPP support

When dm-integrity is used... would that be enough for btrfs to do a
proper repair in the RAID+nodatacow case? I assume it can't do repairs
now there, because how should it know which copy is valid.

 (which you should have access to 
given the amount of funding CERN gets)

Hehe, CERN may get that funding (I don't know),... but the universities
rather don't ;-)

Except it isn't clear with nodatacow, because it might be a false
positive.

Sure, never claimed the opposite... just that I'd expect this to be
less likely than the other way round, and less of a problem in
practise.

SUSE is pathological case of brain-dead defaults.  Snapper needs to 
either die or have some serious sense beat into it.  When you turn
off 
the automatic snapshot generation for everything but updates and set
the 
retention policy to not keep almost everything, it's actually not bad
at 
all.

Well, still, with CoW (unless you have some form of deduplication,
which in e.g. their use case would have to be on the layers below
btrfs), your storage usage will grow probably more significantly than
without.

And as you've mentioned yourself in the other mail, there's still the
issue with fragmentation.

Snapshots work fine with nodatacow, each block gets CoW'ed once when 
it's first written to, and then goes back to being NOCOW.  The only 
caveat is that you probably want to defrag either once everything
has 
been rewritten, or right after the snapshot.

I thought defrag would unshare the reflinks?

Cheers,
Chris.