Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1391645ybz; Thu, 16 Apr 2020 08:21:53 -0700 (PDT) X-Google-Smtp-Source: APiQypL1gco1esypxcS1m+hO/Pimj4B/NYHGwlaDe9N9VzQj9k8hDEzUQj2D0dtTswRNnadw2jQp X-Received: by 2002:a17:906:2ccc:: with SMTP id r12mr10357900ejr.47.1587050512947; Thu, 16 Apr 2020 08:21:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587050512; cv=none; d=google.com; s=arc-20160816; b=TblFE7eem68mdaP2CjpHpTe94ub3hoNpHOPOFMTx0UB1iItQaSm4I5Gr9VO+vV2yjx COI9T8RXPXDQ86x/4OGWb8OKdv/rZJZsdA4EKGTjdbPW/hEow1i8Wl2JDiBIzlA8M+Si BBGp866UZgCsna8ZaijNZ+fDKUcnlynCHCwAMACQP4OGWxMiZBGT7zY244hRQWdEeIoS HseJmWAXo0fpK25rD3S7WUzxO5TulEO3CZCm03kbJSImvgvXGFjibb20nLmkal5732F+ hVxCnf03HMobzHdyHSrU1iWzABCYa6j9UqHG9+zTwgOqZWg1eVU+q556HmYAfO9bA5Bd 5SYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=O8MuYXsvE7OL1PbMhqja88kp4wEg9xjMX+J/wMdirL0=; b=PVxqqolt4OETatTjjPeiDvavVxvmY+dySq3xK9B1F0ZuteL6e79ifiUxE6S/dKkZAP xkAdQ5O4xW6d/k1W6tjUB8+8QAF/Q+3dKcY/Yz38VxTA1Va2zXiGJ1Gclrdt6QSdW3S2 WRGnP2ks0Y98HDe5jUpFHNMOTvYt3BhEwlDW2/yavA+dnKs9hWyiAw20wydQ1woGsWiP Ze6JEV5PYwR7psnw54f6kAyobOIwo+eqZ6X1/W8QMHQy+cI30dkwDXNBGkWElW6ZVi/N eLoP6IYcJg9fugaeN9oVOnN1+Nyk45cwThqgrizsyVAvmmK+Q07m2SlAvnlNlDWpyedy Zw3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZpfNC9hW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jr16si12108307ejb.374.2020.04.16.08.21.28; Thu, 16 Apr 2020 08:21:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ZpfNC9hW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2442436AbgDPPT3 (ORCPT + 99 others); Thu, 16 Apr 2020 11:19:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:34062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2898721AbgDPNsA (ORCPT ); Thu, 16 Apr 2020 09:48:00 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 46CE6208E4; Thu, 16 Apr 2020 13:47:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587044879; bh=B7zhlyybFv1XUG0eUAi325z4c05qgF2+mSwk3uRsExU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZpfNC9hWEgToEHCnkhMWDxGbZmX26Cel9RIpVXUy9kabpMRSVQ9twevYlByF5dsJk nn7MM4FWV3m1rQVgi5CmgqktjO6q6aioJu45VH8qfrXUjjpqLuPFw/Tc3bL+NNBn3/ mRvp8kxAa8zw6tRso+QXb8xsjoQ0s2Q67ht4oQwI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josef Bacik , David Sterba Subject: [PATCH 5.4 140/232] btrfs: set update the uuid generation as soon as possible Date: Thu, 16 Apr 2020 15:23:54 +0200 Message-Id: <20200416131332.494351963@linuxfoundation.org> X-Mailer: git-send-email 2.26.1 In-Reply-To: <20200416131316.640996080@linuxfoundation.org> References: <20200416131316.640996080@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Josef Bacik commit 75ec1db8717a8f0a9d9c8d033e542fdaa7b73898 upstream. In my EIO stress testing I noticed I was getting forced to rescan the uuid tree pretty often, which was weird. This is because my error injection stuff would sometimes inject an error after log replay but before we loaded the UUID tree. If log replay committed the transaction it wouldn't have updated the uuid tree generation, but the tree was valid and didn't change, so there's no reason to not update the generation here. Fix this by setting the BTRFS_FS_UPDATE_UUID_TREE_GEN bit immediately after reading all the fs roots if the uuid tree generation matches the fs generation. Then any transaction commits that happen during mount won't screw up our uuid tree state, forcing us to do needless uuid rescans. Fixes: 70f801754728 ("Btrfs: check UUID tree during mount if required") CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/disk-io.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3057,6 +3057,18 @@ retry_root_backup: fs_info->generation = generation; fs_info->last_trans_committed = generation; + /* + * If we have a uuid root and we're not being told to rescan we need to + * check the generation here so we can set the + * BTRFS_FS_UPDATE_UUID_TREE_GEN bit. Otherwise we could commit the + * transaction during a balance or the log replay without updating the + * uuid generation, and then if we crash we would rescan the uuid tree, + * even though it was perfectly fine. + */ + if (fs_info->uuid_root && !btrfs_test_opt(fs_info, RESCAN_UUID_TREE) && + fs_info->generation == btrfs_super_uuid_tree_generation(disk_super)) + set_bit(BTRFS_FS_UPDATE_UUID_TREE_GEN, &fs_info->flags); + ret = btrfs_verify_dev_extents(fs_info); if (ret) { btrfs_err(fs_info, @@ -3287,8 +3299,6 @@ retry_root_backup: close_ctree(fs_info); return ret; } - } else { - set_bit(BTRFS_FS_UPDATE_UUID_TREE_GEN, &fs_info->flags); } set_bit(BTRFS_FS_OPEN, &fs_info->flags);