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. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
