Re: data DUP

[Alex Elsayed <eternaleye@gmail.com>]

Roger Binns wrote:

> On 27/04/13 14:40, Calvin Walton wrote:
>> Unfortunately, bugfixes in btrfs have tended to be *not* backported;
>> aside from a few special cases, ...
> 
> Your efforts to scare me are admirable, but have failed :-)
> 
> As btrfs development has progressed, the probability of a random user like
> me hitting bugs keeps decreasing.  This is a reflection of the maturity of
> the code base, the increasing number of users, improved test suites, more
> eyes on the code, more diversity in uses etc. As far as I can see,
> backported bugfixes are made when the probability of a bug being
> encountered is significantly higher than the current probabilities, and
> that is why they are rare.
> 
> As for the severity of the rarely hit bugs, the COW nature of the data
> means there is unlikely to be corruption, and if there is then of the most
> recent activity.  Additionally the checksums mean it is possible to
> proactively verify (online) that unexpected corruption hasn't been
> creeping in.
> 
> And if all that fails, I have multiple layers of backups.

I would be *very* hard-pressed to see it as an attempt to scare you - he's 
just saying what is (very consistently) said to others on this list: When 
using btrfs, run a recent kernel :P.

Honestly, even leaving aside the lack of backporting, there are other 
benefits to a recent kernel - things like cross-subvolume reflinks, btrfs 
device replace support being far more efficient than 
add/balance/remove/balance, and a bunch more.