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

Message ID 20170329043940.23655-1-kilobyte@angband.pl
State New
Headers show

Commit Message

Adam Borowski March 29, 2017, 4:39 a.m. UTC
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(+)

Comments

Christoph Anton Mitterer March 29, 2017, 7:27 p.m. UTC | #1
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.
Adam Borowski March 29, 2017, 7:42 p.m. UTC | #2
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.

Patch
diff mbox

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