Re: What is the vision for btrfs fs repair?

[Eric Sandeen <sandeen@redhat.com>]

On 10/10/14 2:35 PM, Austin S Hemmelgarn wrote:
> On 2014-10-10 13:43, Bob Marley wrote:
>> On 10/10/2014 16:37, Chris Murphy wrote:
>>> The fail safe behavior is to treat the known good tree root as
>>> the default tree root, and bypass the bad tree root if it cannot
>>> be repaired, so that the volume can be mounted with default mount
>>> options (i.e. the ones in fstab). Otherwise it's a filesystem
>>> that isn't well suited for general purpose use as rootfs let
>>> alone for boot.
>>> 
>> 
>> A filesystem which is suited for "general purpose" use is a
>> filesystem which honors fsync, and doesn't *ever* auto-roll-back
>> without user intervention.
>> 
>> Anything different is not suited for database transactions at all.
>> Any paid service which has the users database on btrfs is going to
>> be at risk of losing payments, and probably without the company
>> even knowing. If btrfs goes this way I hope a big warning is
>> written on the wiki and on the manpages telling that this
>> filesystem is totally unsuitable for hosting databases performing
>> transactions.
> If they need reliability, they should have some form of redundancy
> in-place and/or run the database directly on the block device;
> because even ext4, XFS, and pretty much every other filesystem can
> lose data sometimes,

Not if i.e. fsync returns.  If the data is gone later, it's a hardware
problem, or occasionally a bug - bugs that are usually found & fixed
pretty quickly.

> the difference being that those tend to give
> worse results when hardware is misbehaving than BTRFS does, because
> BTRFS usually has a old copy of whatever data structure gets
> corrupted to fall back on.

I'm curious, is that based on conjecture or real-world testing?

-Eric