On 2014-10-10 13:43, Bob Marley wrote:
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, 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.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.
Also, you really shouldn't be running databases on a BTRFS filesystem at the moment anyway, because of the significant performance implications.
At most I can suggest that a flag in the metadata be added to allow/disallow auto-roll-back-on-error on such filesystem, so people can decide the "tolerant" vs. "transaction-safe" mode at filesystem creation.
The problem with this is that if the auto-recovery code did run (and IMHO the kernel should spit out a warning to the system log whenever it does), then chances are that you wouldn't have had a consistent view if you had prevented it from running either; and, if the database is properly distributed/replicated, then it should recover by itself.
smime.p7s
Description: S/MIME Cryptographic Signature
