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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4385C433F5 for ; Fri, 27 May 2022 21:37:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351170AbiE0VhS convert rfc822-to-8bit (ORCPT ); Fri, 27 May 2022 17:37:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232882AbiE0VhS (ORCPT ); Fri, 27 May 2022 17:37:18 -0400 Received: from pio-pvt-msa2.bahnhof.se (pio-pvt-msa2.bahnhof.se [79.136.2.41]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D8721D31D for ; Fri, 27 May 2022 14:37:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 598E83F37A; Fri, 27 May 2022 23:37:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igMCAfqSTg75; Fri, 27 May 2022 23:37:13 +0200 (CEST) Received: by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 1E6573F318; Fri, 27 May 2022 23:37:12 +0200 (CEST) Received: from [192.168.0.113] (port=57868) by tnonline.net with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nuhds-0008RS-UG; Fri, 27 May 2022 23:37:12 +0200 Date: Fri, 27 May 2022 23:37:07 +0200 (GMT+02:00) From: Forza To: efkf , linux-btrfs@vger.kernel.org Message-ID: <8c707c6.705b352d.1810773a14f@tnonline.net> In-Reply-To: References: <9a9d16a133c13bed724f2a6a406bd3b6@firemail.cc> <5fd50e9.def5d621.180f273d002@tnonline.net> <4e7fdc9608777774595bf060a028b600@firemail.cc> <33e31083-99d5-b8d8-e082-a1260849b8da@tnonline.net> Subject: Re: Tried to replace a drive in a raid 1 and all hell broke loose MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT X-Mailer: R2Mail2 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org ---- From: efkf -- Sent: 2022-05-27 - 18:28 ---- > On 5/27/22 16:25, Forza wrote >> On 2022-05-27 17:13, efkf@firemail.cc wrote: >>> I had mounted the fs with -o degraded and one drive a couple of times >>> just as a sanity check to make sure the data really is in both drives, >>> i assume this would mount it rw and fall into the category you described. >> >> With Btrfs, this is not good practice. If you mount RAID mirrors >> independently as degraded, the metadata could be updated differently and >> when you combine the drives again, the data would not be the same on >> each device - which would lead to corruption. This is true even for ro >> mounts. ro is a Linux VFS thing, Btrfs will still write to the disk for >> its internal things. > > I don't know much about advanced filesystems but I can imagine scenarious where it would be beneficial to reintroduce an old drive into an array that maybe even has changed without whiping it, The correct way to re-introduce an old device to Btrfs is to first wipe it with 'wipefs' first. I do agree that this is perhaps counter-intuitive as some other raid systems allows to re-add old disks. Btrfs could handle this better, and I know there was a discussion on #btrfs about this a while back. >maybe it's the only one storing the intact copy of an old file. You should mount this drive on another system to recover this file. It is likely to cause serious corruption to try to introduce a drive after changes has been made. (perhaps there is some protection against this, but I've not heard of it). > Anyway, is there a way to check the data is really redundant without trusting the filesystem telling me it's so? Yes, you use 'btrfs scrub' to read all data and metadata blocks from all devices and compare the checksums. If there are problems, scrub will tell you. https://btrfs.readthedocs.io/en/latest/btrfs-scrub.html https://wiki.tnonline.net/w/Btrfs/Scrub > >> Good to hear that you got most of your data back. :) > :) > > I tried another client now, hopefully the attachment has gone through It did. Lots of mismatching metadata. Not sure that kind of problem can be fixed.