[PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

[PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

[Adam Borowski]

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 <kilobyte@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 affd7aada057..a4c3e6628ec1 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3083,6 +3083,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

[PATCH 2/2] btrfs: clear the RAID5/6 incompat flag once no longer needed

[Adam Borowski]

There's no known taint on a filesystem that was RAID5/6 once but has been
since converted to something non-experimental.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
---
 fs/btrfs/disk-io.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index a4c3e6628ec1..c720a7bc1b15 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3089,6 +3089,8 @@ int open_ctree(struct super_block *sb,
 	    BTRFS_BLOCK_GROUP_RAID56_MASK) {
 		btrfs_alert(fs_info,
 		"btrfs RAID5/6 is EXPERIMENTAL and has known data-loss bugs");
+	} else {
+		btrfs_clear_fs_incompat(fs_info, RAID56);
 	}
 
 	/*
-- 
2.11.0

Re: [PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Wed, 2017-03-29 at 06:39 +0200, Adam Borowski wrote:
> 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.

Wouldn't it be much better to disallow:
- creation
AND
- mounting
of btrfs unless some special swtich like:
--yes-i-know-this-is-still-extremely-experimental
is given for the time being?

Normal users typically don't look at any such kernel log messages - and
expert users (who do) anyway know, that it's still unstable.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5930 bytes --]

Re: [PATCH 1/2] btrfs: warn about RAID5/6 being experimental at mount time

[Adam Borowski]

On Wed, Mar 29, 2017 at 09:27:32PM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2017-03-29 at 06:39 +0200, Adam Borowski wrote:
> > 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.
> 
> Wouldn't it be much better to disallow:
> - creation
> AND
> - mounting
> of btrfs unless some special swtich like:
> --yes-i-know-this-is-still-extremely-experimental
> is given for the time being?

I have no preference here.

> Normal users typically don't look at any such kernel log messages - and
> expert users (who do) anyway know, that it's still unstable.

My previous attempt here was https://patchwork.kernel.org/patch/9450035/
in btrfs-progs.  This time I'm submitting a kernel variant, as it won't be
out of sync if you use a modern kernel on a 10 years old RHEL userland.

I can revive that -progs patch, and fix code issues (ie, printing the
message during parsing); I'd like to hear whether kernel or -progs is
better.  We can even do both.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!