From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.domeneshop.no ([194.63.252.55]:51830 "EHLO smtp.domeneshop.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750818AbdCDKGJ (ORCPT ); Sat, 4 Mar 2017 05:06:09 -0500 Reply-To: waxhead@dirtcellar.net Subject: Re: raid1 degraded mount still produce single chunks, writeable mount not allowed To: Chris Murphy Cc: Qu Wenruo , Peter Grandi , Linux Btrfs , Austin S Hemmelgarn References: <22712.48434.400550.346157@tree.ty.sabi.co.uk> From: waxhead Message-ID: <6bbc2561-3db3-8d7c-b039-0521c7b9b9ab@dirtcellar.net> Date: Sat, 4 Mar 2017 10:55:35 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: Chris Murphy wrote: > On Thu, Mar 2, 2017 at 6:48 PM, Chris Murphy wrote: > >> Again, my data is fine. The problem I'm having is this: >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/filesystems/btrfs.txt?id=refs/tags/v4.10.1 >> >> Which says in the first line, in part, "focusing on fault tolerance, >> repair and easy administration" and quite frankly this sort of >> enduring bug in this file system that's nearly 10 years old now, is >> rendered misleading, and possibly dishonest. How do we describe this >> file system as focusing on fault tolerance when, in the identical >> scenario using mdadm or LVM raid, the user's data is not mishandled >> like it is on Btrfs with multiple devices? > > I think until these problems are fixed, the Btrfs status page should > describe RAID 1 and 10 as mostly OK, with this problem as the reason > for it not being OK. > I took the liberty of changing the status page...