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.
smime.p7s
Description: S/MIME cryptographic signature
