Received-SPF: pass (google.com: domain of linux-kernel+bounces-180234-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Naohiro Aota <Naohiro.Aota@wdc.com>
To: Johannes Thumshirn <jth@kernel.org>
CC: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>, David Sterba
	<dsterba@suse.com>, Hans Holmberg <Hans.Holmberg@wdc.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Johannes
 Thumshirn <Johannes.Thumshirn@wdc.com>
Subject: Re: [PATCH 1/2] btrfs: zoned: reserve relocation zone on mount
Thread-Topic: [PATCH 1/2] btrfs: zoned: reserve relocation zone on mount
Thread-Index: AQHapkOfs6XfoKOaFU6yKgJdnaEZG7GYllqA
Date: Wed, 15 May 2024 17:58:23 +0000
Message-ID: <5tffp7f57i7f4om4tiqyamn463onnzkswbn4bathr2xkrhx5cv@fqfykq5t23al>
References: <20240514-zoned-gc-v1-0-109f1a6c7447@kernel.org>
 <20240514-zoned-gc-v1-1-109f1a6c7447@kernel.org>
In-Reply-To: <20240514-zoned-gc-v1-1-109f1a6c7447@kernel.org>
Accept-Language: ja-JP, en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?us-ascii?Q?59oIFv3/3bHN+9u7k0e7M7N848wgGxH4Om/FjTpT3C5Pblosdw0u7ak11JsC?=
 =?us-ascii?Q?xsKyVJlwl4uJs/K+YS5CYtX1+Mqq3UN25NoP6j3Ku+ppfbOpReU4L+lcGKnd?=
 =?us-ascii?Q?WfpHjD9/J31wsU7TdNfuOciA0rRfhGQZTheA8vc2NoHkO5xrFb5pwSCPCh8M?=
 =?us-ascii?Q?v9mBdAEJ+dqYfP8tWLlVmwl1hKZzd644ATH9cv3C3fCfEm8ZphIjh2zqThTt?=
 =?us-ascii?Q?xMtSPnIStDJ8HqZfRmbbyJA0VSECGFEXkZGiuvh3M8K/+kgMciywg26/PZyr?=
 =?us-ascii?Q?yf5QN+Bm0RSUKaDEkc52XEBzN6dl7MPMseY0uip14oBA+tpBJqa0hRwil81u?=
 =?us-ascii?Q?pZ58JYov1Z3kDVkZNtIIT5Dm4xzPLRhQpEiIXg48jiHMUTqOxLzH1f/42rKk?=
 =?us-ascii?Q?qO3L0Gw+DQABiCAP61c3AsdYQ734NVmz5ke8BYOK75iXPf939Dr9vZ6sTAtN?=
 =?us-ascii?Q?UdSaia6vUHppEv9LR5TZI1t5V0ZJmGhGP14RXNHyJ/SXCGXlBLaaTTPbE3Ef?=
 =?us-ascii?Q?e4cI2s6XOOAHvoInSi/Isyyz9LjInCVjV8h5t0gE5a52Jy03oP6HRd91U+t+?=
 =?us-ascii?Q?kZF/clbRQZcInb2nvo2H1gkNz14NWIzLkiZNRhwYCUkld/Xe624mu16Fpegr?=
 =?us-ascii?Q?ie97BvnTMifIfo/fOESCmewDhLKLVL27iKaw3FFykHYmLwNrnGbVW1NHJDUh?=
 =?us-ascii?Q?iIk/0ob+5d5lYlfYIMTyG/M9OeyGFAgP9j3GotZjaaeUKt2HNOa6wPjvn4r8?=
 =?us-ascii?Q?5+FB9/ogoVFfaTi4qB548F/QpfCbvu4PiNsZpIt617XrG0Vo0Y+Pz+3ntDbI?=
 =?us-ascii?Q?CK3LYlA6+eMC8Nl3lIWXd4TJP1XHYzjiFRFHZgqGxpqQ2glTcXS1ISAYF7XP?=
 =?us-ascii?Q?UkwTYBrPm40ImQiVGmVUJd4WSZdLLtrWRMH5Y6c1OWk8/e49FShrJOj1ERFg?=
 =?us-ascii?Q?joYo8sNIPuDTxskZ3byRfTT2ZpiP0EJYmiQfdlXiDMnERim/vYyqmXoVAu7h?=
 =?us-ascii?Q?hK1jc/e/Gg/5wp6yPnOBReoyaL44jLXNn23j5kAErIAHIxfmn1Dny4awDDm2?=
 =?us-ascii?Q?FxPEjjkH3GKJReu/n20epqy8JLYXzOd/CHTAWEu3h1WK1/Jl59zoime2XaO0?=
 =?us-ascii?Q?VnmAc+L5cNv1O54KXCLohDZWl6RF+nvyCpwWfecZKPBsbso2PH3TCzqicPWG?=
 =?us-ascii?Q?+oLK2FirOACr7WL38Vwur+3ByQ41YyabrPwxShV+9o2+ECLyDsutYLDkBitg?=
 =?us-ascii?Q?wSbXTNUY9Rhd0X3l0xTMW2kn4zFO4gbcvg3pENkx5U9EPigjLk46Ih6qRVBv?=
 =?us-ascii?Q?+9YtYlkZ4UivXHFlNnM3HHyu9ktKX/3TCL2ujcCJglOfrxWak5Jhmiy5a9Nq?=
 =?us-ascii?Q?o0RYokS9fBwkS8D4TszisoD4H2Pvgs+Z8XpVarZeLHmimgudehK5h3k33dt3?=
 =?us-ascii?Q?JoLCwEeHO1+edBQTWQSNmzxbnESPgNmZBQhrrAYJBdgjmVJQjWzWy/WmBubJ?=
 =?us-ascii?Q?v/yEPkNgL/cjeFJedYUh2Px7edHvzNZwQelqHswV8bARc73FJHCHIk+Cyjm1?=
 =?us-ascii?Q?yCNM6Y/WYeTPSYlu0HOVkl1+HHE9TOZY6eofkOYd?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0B033B655EA7284EA5F8CC79DA470225@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
	t5q0y8pJQmSB7pLo0SCPfbNow57yFr5Hdtmp4hyZeSUi5ZQ4b5E9IeZ7i62rmy5vTHcWij1lbt0Bs2Xf/ZnrPnO0IxGK/6HDEadCS6oQJHVWtf6yn/Gt4NaqqQKI2gA3eY3fUH0DeY7nTezUbna8WB54eY7tNyjwgBjQqFaRB2GcBLmFwyQHKcCHrSNCRid/x5UvXGLa7Z6IMSX44BCw2lQu+aL/SRKUT+L8xVbMWOmNsCHurJlWsKU84vrGS4asqtwwl/IGY5mAAv14ye4t3LplU8QHUNC5mmAsCDbhEFCTkeXqgbDDolIyPgIaRn7eFq6Fl0Dk+eiXXIfVPyO64PmeHZHKHUhWpPIfpSRbSMQ/VPUy28ly8t6lOkLpt9o6R6zLIO0x1jbI85aqA8MgzEr6kKq0q6yLV0rNHaRJnHPjGBxCVChY2bfdx1e7/i+Z41cJHj3Or+GxUvMOnHY9/CKliFd+cgXHaoFrjtndso67g/GeqzyiB8sGIYvrSzlnpYPNSWvj2WALzhoTd6i9rQekjius1YfB+EsT7wcc2i5Y4xXRBsujbAx8UMxvULwVdRUJY4X+zKCF+3YoIssDrn3avgU7S1TZe9LxZa2EZzWz3+aJRqDNi24qDGkXr+Mn
X-OriginatorOrg: wdc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR04MB7776.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 91bc79c5-f73b-4045-02f3-08dc75089d65
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2024 17:58:24.0503
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jmYXzgN68h/6q8nXAPV/8EukrIHbYRoNNcjUdeRvu7nmV2np0NSwxf2ynvEErdbG80oKb0ZW7nMl+kpHP70atg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR04MB8613

On Tue, May 14, 2024 at 11:13:21PM +0200, Johannes Thumshirn wrote:
> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>=20
> Reserve one zone as a data relocation target on each mount. If we already
> find one empty block group, there's no need to force a chunk allocation,
> but we can use this empty data block group as our relocation target.
>=20
> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
> ---
>  fs/btrfs/disk-io.c |  2 ++
>  fs/btrfs/zoned.c   | 60 ++++++++++++++++++++++++++++++++++++++++++++++++=
++++++
>  fs/btrfs/zoned.h   |  3 +++
>  3 files changed, 65 insertions(+)
>=20
> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
> index a91a8056758a..0490f2f45fb1 100644
> --- a/fs/btrfs/disk-io.c
> +++ b/fs/btrfs/disk-io.c
> @@ -3558,6 +3558,8 @@ int __cold open_ctree(struct super_block *sb, struc=
t btrfs_fs_devices *fs_device
>  	}
>  	btrfs_discard_resume(fs_info);
> =20
> +	btrfs_reserve_relocation_zone(fs_info);
> +
>  	if (fs_info->uuid_root &&
>  	    (btrfs_test_opt(fs_info, RESCAN_UUID_TREE) ||
>  	     fs_info->generation !=3D btrfs_super_uuid_tree_generation(disk_sup=
er))) {
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 4cba80b34387..b752f8c95f40 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -17,6 +17,7 @@
>  #include "fs.h"
>  #include "accessors.h"
>  #include "bio.h"
> +#include "transaction.h"
> =20
>  /* Maximum number of zones to report per blkdev_report_zones() call */
>  #define BTRFS_REPORT_NR_ZONES   4096
> @@ -2634,3 +2635,62 @@ void btrfs_check_active_zone_reservation(struct bt=
rfs_fs_info *fs_info)
>  	}
>  	spin_unlock(&fs_info->zone_active_bgs_lock);
>  }
> +
> +static u64 find_empty_block_group(struct btrfs_space_info *sinfo, u64 fl=
ags)
> +{
> +	struct btrfs_block_group *bg;
> +
> +	for (int i =3D 0; i < BTRFS_NR_RAID_TYPES; i++) {
> +		list_for_each_entry(bg, &sinfo->block_groups[i], list) {
> +			if (bg->flags !=3D flags)
> +				continue;
> +			if (bg->used =3D=3D 0)
> +				return bg->start;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +void btrfs_reserve_relocation_zone(struct btrfs_fs_info *fs_info)

This function reserves the data relocation block group but not a zone. So,
I'd prefer "btrfs_reserve_relocation_block_group" or "..._bg".

> +{
> +	struct btrfs_root *tree_root =3D fs_info->tree_root;
> +	struct btrfs_space_info *sinfo =3D fs_info->data_sinfo;
> +	struct btrfs_trans_handle *trans;
> +	u64 flags =3D btrfs_get_alloc_profile(fs_info, sinfo->flags);
> +	u64 bytenr =3D 0;
> +
> +	lockdep_assert_not_held(&fs_info->relocation_bg_lock);
> +
> +	if (!btrfs_is_zoned(fs_info))
> +		return;
> +

Don't we need to check fs_info->data_reloc_bg first? If we don't find an
empty BG and we fail to allocate a new BG, this is going to kill the
existing data reloc BG. It's OK for mount time. But, this is going to be
called on runtime in the next patch.

> +	bytenr =3D find_empty_block_group(sinfo, flags);
> +	if (!bytenr) {
> +		int ret;
> +
> +		trans =3D btrfs_join_transaction(tree_root);
> +		if (IS_ERR(trans))
> +			return;
> +
> +		ret =3D btrfs_chunk_alloc(trans, flags, CHUNK_ALLOC_FORCE);
> +		btrfs_end_transaction(trans);

I'd like to have a comment on the error case, especially relates to the
above point. Is it OK to override fs_info->data_reloc_bg to 0 in the error
case?

> +
> +		if (!ret) {
> +			struct btrfs_block_group *bg;
> +
> +			bytenr =3D find_empty_block_group(sinfo, flags);
> +			if (!bytenr)

Maybe, same here. This is a case of someone stealing the allocated
chunk. Isn't it worth retrying? Especially when this function is called on
runtime?

> +				goto out;
> +			bg =3D btrfs_lookup_block_group(fs_info, bytenr);
> +			ASSERT(bg);
> +
> +			if (!btrfs_zone_activate(bg))
> +				bytenr =3D 0;
> +			btrfs_put_block_group(bg);
> +		}
> +	}
> +
> +out:
> +	fs_info->data_reloc_bg =3D bytenr;
> +}
> diff --git a/fs/btrfs/zoned.h b/fs/btrfs/zoned.h
> index 77c4321e331f..048ffada4549 100644
> --- a/fs/btrfs/zoned.h
> +++ b/fs/btrfs/zoned.h
> @@ -97,6 +97,7 @@ int btrfs_zone_finish_one_bg(struct btrfs_fs_info *fs_i=
nfo);
>  int btrfs_zoned_activate_one_bg(struct btrfs_fs_info *fs_info,
>  				struct btrfs_space_info *space_info, bool do_finish);
>  void btrfs_check_active_zone_reservation(struct btrfs_fs_info *fs_info);
> +void btrfs_reserve_relocation_zone(struct btrfs_fs_info *fs_info);
>  #else /* CONFIG_BLK_DEV_ZONED */
>  static inline int btrfs_get_dev_zone(struct btrfs_device *device, u64 po=
s,
>  				     struct blk_zone *zone)
> @@ -271,6 +272,8 @@ static inline int btrfs_zoned_activate_one_bg(struct =
btrfs_fs_info *fs_info,
> =20
>  static inline void btrfs_check_active_zone_reservation(struct btrfs_fs_i=
nfo *fs_info) { }
> =20
> +static inline void btrfs_reserve_relocation_zone(struct btrfs_fs_info *f=
s_info) { }
> +
>  #endif
> =20
>  static inline bool btrfs_dev_is_sequential(struct btrfs_device *device, =
u64 pos)
>=20
> --=20
> 2.35.3
> =