From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A220DC54FD0 for ; Mon, 27 Apr 2020 11:44:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7AA8A2063A for ; Mon, 27 Apr 2020 11:44:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727025AbgD0Lok (ORCPT ); Mon, 27 Apr 2020 07:44:40 -0400 Received: from len.romanrm.net ([91.121.86.59]:47338 "EHLO len.romanrm.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726989AbgD0Lok (ORCPT ); Mon, 27 Apr 2020 07:44:40 -0400 Received: from natsu (natsu.40.romanrm.net [IPv6:fd39:aa:c499:6515:e99e:8f1b:cfc9:ccb8]) by len.romanrm.net (Postfix) with SMTP id 70A3340229; Mon, 27 Apr 2020 11:44:36 +0000 (UTC) Date: Mon, 27 Apr 2020 16:44:36 +0500 From: Roman Mamedov To: Marc Lehmann Cc: Hugo Mills , linux-btrfs@vger.kernel.org Subject: Re: questoin about Data=single on multi-device fs Message-ID: <20200427164436.05c5c257@natsu> In-Reply-To: <20200427112946.GA3648@schmorp.de> References: <20200426100405.GA5270@schmorp.de> <20200426102547.GM32577@savella.carfax.org.uk> <20200427112946.GA3648@schmorp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org On Mon, 27 Apr 2020 13:29:47 +0200 Marc Lehmann wrote: > On Sun, Apr 26, 2020 at 11:25:47AM +0100, Hugo Mills wrote: > > > The reason I chose data=single was specifically to help in case of device > > > loss at the cost of performance. > > > > Make backups. That's the only way to be sure about this sort of thing. > > I think you are unthinkingly repeating a wrong (and slightly dangerous) > claim - backups cannot actually do that sort of thing: a raid will protect > against (some amount of) disk failures with no data loss, but backups > cannot: Backups can protect against complete data loss, but cannot > completely protect against data loss. With backups it is at least clear enough to anyone that only the data that has been backed up will be recoverable from the backup; On the other hand you follow a much more dangerous theory, that a low-level JBOD-style merging of disks can be of any significant "help" in case of a device failure. That's often heard applied to LVM LVs spanned across multiple devices, or MD Linear, or in this case Btrfs "single". In all of those cases I have to wonder how getting to keep a few chunks of what some time ago was a filesystem, or in your case, *random pieces of random files* being luckily intact, will be of any help and alleviate the need to restore from backups. If you really want a JBOD-style storage merged into a single pool, with device failures having impact limited only to that device, better look into FUSE file-level overlay filesystems, such as MergerFS and MHDDFS. At least with those you are guaranteed to have whole files intact on still running devices. Exactly what Btrfs doesn't guarantee you now (seemingly even more so), but most importantly never did, not even on any prior kernel version. -- With respect, Roman