Package: src:linux
Version: 4.9.25-1
Severity: grave
Tags: patch
(Not sure what an appropriate severity is -- very likely total filesystem
loss screams "critical" but "please add a warning" might be even wishlist.)
Btrfs, while stable and reliable when using a subset of features, or at
least reasonable with some caveats on a bigger feature set, also includes a
couple of experimental eats-data-babies-and-kittens features. The problem
is, (shouting warranted) THERE'S NO MENTION WHATSOEVER THEY'RE BROKEN!!!
One of those features, qgroups, notoriously causes bogus ENOSPC and kills
performance, but at least leaves data recoverable.
RAID5/6, not so. It suffers from a number of both implementation and design
errors, resulting in frequent data loss. Even worse, when such data loss
happens, in a good majority of cases you lose the whole filesystem.
Known implementation issues are mostly fixed in 4.12 (except for 32-bit
kernels which still insta-die the moment you say "scrub"), the design one
(write hole) will be harder to fix but is nowhere as nasty; because of
metadata write patterns, it is still likely to result in whole filesystem
loss but that's easily workable around -- btrfs supports different raid
levels for data-vs-metadata so an adventureous user might live with a
-draid5 -mraid1 profile. On 4.12.
The last I checked, however, Stretch has kernel 4.9.
There's some discussion on the btrfs mailing list, but it is going quite
slowly; way too slow for a warning to filter past the usual channels
(mainline->GregKH->you) in time for Stretch.
It looks like there's a consensus that such a warning should live in the
kernel rather than userland -- on 4.12 64-bit -draid5/6 is already nowhere
as bad, it's very common to use new kernels on old userland. This means my
beautiful fiery letters from
https://www.spinics.net/lists/linux-btrfs/msg60913.html will remain unused.
There's no config setting to disable RAID5/6, such a setting would also make
it hard to migrate to supported raid levels as you need to mount rw in order
to convert. And, you really hate non-trivial divergences from upstream.
A proposed warning patch attached.
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.12.0-rc1-debug-00011-gb82803d91ae5 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From 5ce4e611eab1a451332e0745ee91f787057e929b Mon Sep 17 00:00:00 2001
From: Adam Borowski <kilob...@angband.pl>
Date: Tue, 28 Mar 2017 16:55:05 +0200
Subject: [PATCH] btrfs: warn about RAID5/6 being experimental at mount time
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski <kilob...@angband.pl>
---
fs/btrfs/disk-io.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 8685d67185d0..6aad1110602e 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3068,6 +3068,14 @@ int open_ctree(struct super_block *sb,
btrfs_set_opt(fs_info->mount_opt, SSD);
}
+ if ((fs_info->avail_data_alloc_bits |
+ fs_info->avail_metadata_alloc_bits |
+ fs_info->avail_system_alloc_bits) &
+ BTRFS_BLOCK_GROUP_RAID56_MASK) {
+ btrfs_alert(fs_info,
+ "btrfs RAID5/6 is EXPERIMENTAL and has known data-loss bugs");
+ }
+
/*
* Mount does not set all options immediately, we can do it now and do
* not have to wait for transaction commit
--
2.11.0
