| Message ID | 20170329043940.23655-1-kilobyte@angband.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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.
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
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(+)