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