Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2163867iof; Tue, 7 Jun 2022 21:53:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZuNltixdaXgFujjLj5mSUn5IGMSJC/k0mBj7jJw8jpJH24foKi6xT3W/UejkYrq4ZcZjj X-Received: by 2002:a63:4844:0:b0:3fc:c299:a7a4 with SMTP id x4-20020a634844000000b003fcc299a7a4mr28272173pgk.510.1654663986306; Tue, 07 Jun 2022 21:53:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654663986; cv=none; d=google.com; s=arc-20160816; b=B4uF91UItJzP/kihz6y1W3dJOl4GqCiOi0uNYREPMRpuazGpTO5c8JwvXEI+OIABqT 4dioIN3HI/oi6NkNFIEpbV8vjMICnBc6kE+2j9k0y0JvaZz501+2RTfGzZqzaJBEoxUF eTUiuP3dcS3VCBr6+wEdNySa+dDPnPg6ZjnKq6jf90MWayGONWjS47taPKLVpbj2g5dh j6KDg4Ynn4w0zwgWwF4Os5U5UD227Xq5J+3hnPtvysXfojktzeFssS76lMCKpWiHmnsd tzQfYbJXnytmQJTrIDkSRgdrzFOJoZ9QsSMcEdX+iOglVmRMH6+IvQjBVGRQbDOa4QTT xmCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=c07Zn1HxRSxMuN8VonDWhjQCG4muOHxm9bSsaOc3T0w=; b=Ga3B55ZEXsni8R8Bu+7FK4ESTDus8exVREqzuaD11IfWj9VEMKcmKWeyEA9aPHtoaE joORrixf+HOshON4pjpa4RBMDTfy6hpVJNK5prkFtNEgQ4ZfRHSNXzehHn1h32j10ZzQ tzN5EO0jIckioEmWEiOQeUTjQMNFFNCmTp9boyelVn20r8eej4d0OQOSDR7I/ya1ijNA 1FaNiPQwSB6CWJ2mx7hWhfSItqdM3IwVhr19JroslEhrzCq3RVs+xlaomy1s54N4UvCX wLD9a8dlIyx0YqC+2MybbGd5lnuPmyW0LCcr08wcH6JaL1G40yUTztc8K61squ0U+cgR nLmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yhekfF3Q; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id h71-20020a63834a000000b003fe2a4341d9si1758861pge.354.2022.06.07.21.53.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 21:53:06 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yhekfF3Q; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1058320A094; Tue, 7 Jun 2022 21:22:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242719AbiFGRUi (ORCPT + 99 others); Tue, 7 Jun 2022 13:20:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345685AbiFGRTE (ORCPT ); Tue, 7 Jun 2022 13:19:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C5691053FD; Tue, 7 Jun 2022 10:19:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 907B6B82239; Tue, 7 Jun 2022 17:18:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8D2FC341C0; Tue, 7 Jun 2022 17:18:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654622338; bh=A7eaECiv2vQDkwyli5GuWMn2aASk7JkFATOo2W8Bw+Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yhekfF3QqEGc17auuM6/mnY58t7TD9nXh4ubcNr8hO9Q5lagfPzJyS2zcujcix+ex pYmbuORYMoY+zA7rEFVQnSTOvR2EzQSS6+xU9Td+nDQOfJ+kSUaKK8y23wN7W1mDS+ K4+C6KYAL0tK+RCtlISw1zf7xB7OPkQXPdb1ze90= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Luca=20B=C3=A9la=20Palkovics?= , Qu Wenruo , David Sterba Subject: [PATCH 5.10 023/452] btrfs: repair super block num_devices automatically Date: Tue, 7 Jun 2022 18:58:00 +0200 Message-Id: <20220607164909.235093202@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164908.521895282@linuxfoundation.org> References: <20220607164908.521895282@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Qu Wenruo commit d201238ccd2f30b9bfcfadaeae0972e3a486a176 upstream. [BUG] There is a report that a btrfs has a bad super block num devices. This makes btrfs to reject the fs completely. BTRFS error (device sdd3): super_num_devices 3 mismatch with num_devices 2 found here BTRFS error (device sdd3): failed to read chunk tree: -22 BTRFS error (device sdd3): open_ctree failed [CAUSE] During btrfs device removal, chunk tree and super block num devs are updated in two different transactions: btrfs_rm_device() |- btrfs_rm_dev_item(device) | |- trans = btrfs_start_transaction() | | Now we got transaction X | | | |- btrfs_del_item() | | Now device item is removed from chunk tree | | | |- btrfs_commit_transaction() | Transaction X got committed, super num devs untouched, | but device item removed from chunk tree. | (AKA, super num devs is already incorrect) | |- cur_devices->num_devices--; |- cur_devices->total_devices--; |- btrfs_set_super_num_devices() All those operations are not in transaction X, thus it will only be written back to disk in next transaction. So after the transaction X in btrfs_rm_dev_item() committed, but before transaction X+1 (which can be minutes away), a power loss happen, then we got the super num mismatch. This has been fixed by commit bbac58698a55 ("btrfs: remove device item and update super block in the same transaction"). [FIX] Make the super_num_devices check less strict, converting it from a hard error to a warning, and reset the value to a correct one for the current or next transaction commit. As the number of device items is the critical information where the super block num_devices is only a cached value (and also useful for cross checking), it's safe to automatically update it. Other device related problems like missing device are handled after that and may require other means to resolve, like degraded mount. With this fix, potentially affected filesystems won't fail mount and require the manual repair by btrfs check. Reported-by: Luca Béla Palkovics Link: https://lore.kernel.org/linux-btrfs/CA+8xDSpvdm_U0QLBAnrH=zqDq_cWCOH5TiV46CKmp3igr44okQ@mail.gmail.com/ CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/volumes.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7191,12 +7191,12 @@ int btrfs_read_chunk_tree(struct btrfs_f * do another round of validation checks. */ if (total_dev != fs_info->fs_devices->total_devices) { - btrfs_err(fs_info, - "super_num_devices %llu mismatch with num_devices %llu found here", + btrfs_warn(fs_info, +"super block num_devices %llu mismatch with DEV_ITEM count %llu, will be repaired on next transaction commit", btrfs_super_num_devices(fs_info->super_copy), total_dev); - ret = -EINVAL; - goto error; + fs_info->fs_devices->total_devices = total_dev; + btrfs_set_super_num_devices(fs_info->super_copy, total_dev); } if (btrfs_super_total_bytes(fs_info->super_copy) < fs_info->fs_devices->total_rw_bytes) {