From patchwork Mon Jun 13 07:06:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 12879102 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 149A9C43334 for ; Mon, 13 Jun 2022 07:07:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236838AbiFMHHV (ORCPT ); Mon, 13 Jun 2022 03:07:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56900 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238839AbiFMHG5 (ORCPT ); Mon, 13 Jun 2022 03:06:57 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AA1A19022 for ; Mon, 13 Jun 2022 00:06:56 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4DD7E1F98F for ; Mon, 13 Jun 2022 07:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1655104015; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KAjWrd8ckaCLtxC0eNSiNN6q1Bi1IQCCF5aHKcufwVw=; b=MpcV1Sjb5zoHaGbB7dSxHlidvz8LJLsnAL78swtH7Sv5VNR8di8ty4bIAV/9l8T2biB2v9 3wgafWlaRz3at2cAbPy0SyihP2U9A/5SGdLhWR7apwZ9mZzrgg8D3z0popyid9iYAqds9g GZPvnuGY2n+/GT/1+HyichlR6v8ZTqw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8EAAD134CF for ; Mon, 13 Jun 2022 07:06:54 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id mEhWFA7ipmJUCgAAMHmgww (envelope-from ) for ; Mon, 13 Jun 2022 07:06:54 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH 1/2] btrfs: introduce BTRFS_DEFAULT_RESERVED macro Date: Mon, 13 Jun 2022 15:06:34 +0800 Message-Id: <51b17f7480724d528e709a920acd026acff447ea.1655103954.git.wqu@suse.com> X-Mailer: git-send-email 2.36.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Since btrfs-progs v4.1, mkfs.btrfs will reserve the first 1MiB for the primary super block (at offset 64KiB) and other legacy bootloaders which may want to store their data there. Kernel is doing the same behavior around the same time. However in kernel we just use SZ_1M to express the reserved space, normally with extra comments when using above SZ_1M. Here we introduce a new macro, BTRFS_DEFAULT_RESERVED to replace such SZ_1M usage. This will make later enlarged per-dev reservation easier to implement. Signed-off-by: Qu Wenruo --- fs/btrfs/ctree.h | 7 +++++++ fs/btrfs/extent-tree.c | 6 +++--- fs/btrfs/super.c | 10 +++++----- fs/btrfs/volumes.c | 7 +------ 4 files changed, 16 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index f7afdfd0bae7..62028e7d5799 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -229,6 +229,13 @@ struct btrfs_root_backup { #define BTRFS_SUPER_INFO_OFFSET SZ_64K #define BTRFS_SUPER_INFO_SIZE 4096 +/* + * The default reserved space for each device. + * This range covers the primary superblock, and some other legacy programs like + * older bootloader may want to store their data there. + */ +#define BTRFS_DEFAULT_RESERVED (SZ_1M) + /* * the super block basically lists the main trees of the FS * it currently lacks any block count etc etc diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 8e9f0a99b292..e384dd483eaa 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5976,7 +5976,7 @@ int btrfs_error_unpin_extent_range(struct btrfs_fs_info *fs_info, */ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) { - u64 start = SZ_1M, len = 0, end = 0; + u64 start = BTRFS_DEFAULT_RESERVED, len = 0, end = 0; int ret; *trimmed = 0; @@ -6020,8 +6020,8 @@ static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed) break; } - /* Ensure we skip the reserved area in the first 1M */ - start = max_t(u64, start, SZ_1M); + /* Ensure we skip the reserved area of each device. */ + start = max_t(u64, start, BTRFS_DEFAULT_RESERVED); /* * If find_first_clear_extent_bit find a range that spans the diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 719dda57dc7a..c2d051e887be 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -2273,16 +2273,16 @@ static inline int btrfs_calc_avail_data_space(struct btrfs_fs_info *fs_info, /* * In order to avoid overwriting the superblock on the drive, - * btrfs starts at an offset of at least 1MB when doing chunk - * allocation. + * btrfs has some reserved space at the beginning of each + * device. * * This ensures we have at least min_stripe_size free space - * after excluding 1MB. + * after excluding that reserved space. */ - if (avail_space <= SZ_1M + min_stripe_size) + if (avail_space <= BTRFS_DEFAULT_RESERVED + min_stripe_size) continue; - avail_space -= SZ_1M; + avail_space -= BTRFS_DEFAULT_RESERVED; devices_info[i].dev = device; devices_info[i].max_avail = avail_space; diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 12a6150ee19d..051d124679d1 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -1396,12 +1396,7 @@ static u64 dev_extent_search_start(struct btrfs_device *device, u64 start) { switch (device->fs_devices->chunk_alloc_policy) { case BTRFS_CHUNK_ALLOC_REGULAR: - /* - * We don't want to overwrite the superblock on the drive nor - * any area used by the boot loader (grub for example), so we - * make sure to start at an offset of at least 1MB. - */ - return max_t(u64, start, SZ_1M); + return max_t(u64, start, BTRFS_DEFAULT_RESERVED); case BTRFS_CHUNK_ALLOC_ZONED: /* * We don't care about the starting region like regular From patchwork Mon Jun 13 07:06:35 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Qu Wenruo X-Patchwork-Id: 12879103 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 241F3CCA47B for ; Mon, 13 Jun 2022 07:07:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238808AbiFMHHW (ORCPT ); Mon, 13 Jun 2022 03:07:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233144AbiFMHG7 (ORCPT ); Mon, 13 Jun 2022 03:06:59 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 06EFE19C20 for ; Mon, 13 Jun 2022 00:06:58 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B19C81FABD for ; Mon, 13 Jun 2022 07:06:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1655104016; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=65Wx0Usn2VXbYmkZ773JLVNg3GQ7HDzk0KBKaty8l4o=; b=u2/B7rHNzxlQ/d+R5U6vEqUsQHDuYybg9sJf18V+6HGveI8zx273sbBFN2XOAr/vgu9R6d jTIqcfH3rLfzB+n0XgDts0NeVJp7UVBEvb1UunHcVXcIiORv1arRscON9DgYYKPF+Kx9YJ IMSkIXRIS2ryP9swVb4MdXH7ZYwiO7U= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id BD33C134CF for ; Mon, 13 Jun 2022 07:06:55 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id MIKmHw/ipmJUCgAAMHmgww (envelope-from ) for ; Mon, 13 Jun 2022 07:06:55 +0000 From: Qu Wenruo To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/2] btrfs: warn about dev extents that are inside the reserved range Date: Mon, 13 Jun 2022 15:06:35 +0800 Message-Id: X-Mailer: git-send-email 2.36.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Btrfs has reserved the first 1MiB for the primary super block (at 64KiB offset) and legacy programs like older bootloaders. This behavior is only introduced since v4.1 btrfs-progs release, although kernel can ensure we never touch the reserved range of super blocks, it's better to inform the end users, and a balance will resolve the problem. Signed-off-by: Qu Wenruo --- fs/btrfs/volumes.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 051d124679d1..b39f4030d2ba 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7989,6 +7989,16 @@ static int verify_one_dev_extent(struct btrfs_fs_info *fs_info, goto out; } + /* + * Very old mkfs.btrfs (before v4.1) will not respect the reserved + * space. Although kernel can handle it without problem, better to + * warn the users. + */ + if (physical_offset < BTRFS_DEFAULT_RESERVED) + btrfs_warn(fs_info, +"devid %llu physical %llu len %llu is inside the reserved space, balance is needed to solve this problem.", + devid, physical_offset, physical_len); + for (i = 0; i < map->num_stripes; i++) { if (map->stripes[i].dev->devid == devid && map->stripes[i].physical == physical_offset) {