All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: introduce BTRFS_DEFAULT_RESERVED macro
Date: Mon, 13 Jun 2022 12:13:44 +0300	[thread overview]
Message-ID: <24bd65b9-d382-f55b-3640-add00b02f4e3@suse.com> (raw)
In-Reply-To: <51b17f7480724d528e709a920acd026acff447ea.1655103954.git.wqu@suse.com>



On 13.06.22 г. 10:06 ч., Qu Wenruo wrote:
> 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 <wqu@suse.com>
> ---
>   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 name of this macros is too generic and uninformative. How about 
BTRFS_BOOT_RESERVED or simply BTRFS_RESERVED_SPACE, because 
BTRFS_DEFAULT_RESERVED implies  there is something else, apart from 
"default" and there won't be ...

<snip>

  reply	other threads:[~2022-06-13  9:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-13  7:06 [PATCH 0/2] btrfs: cleanup related to the 1MiB reserved space Qu Wenruo
2022-06-13  7:06 ` [PATCH 1/2] btrfs: introduce BTRFS_DEFAULT_RESERVED macro Qu Wenruo
2022-06-13  9:13   ` Nikolay Borisov [this message]
2022-06-13  9:36     ` Qu Wenruo
2022-06-16 15:20       ` David Sterba
2022-06-17  1:47         ` Qu Wenruo
2022-06-17 14:04           ` David Sterba
2022-06-13  7:06 ` [PATCH 2/2] btrfs: warn about dev extents that are inside the reserved range Qu Wenruo
2022-06-13 19:05   ` Boris Burkov
2022-06-14  7:48     ` Qu Wenruo
2022-06-14 15:30       ` Boris Burkov
2022-06-14 22:12         ` Qu Wenruo
2022-06-16 15:03           ` David Sterba
2022-06-13 18:20 ` [PATCH 0/2] btrfs: cleanup related to the 1MiB reserved space David Sterba
2022-06-13 23:50   ` Qu Wenruo
2022-06-14 13:56     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24bd65b9-d382-f55b-3640-add00b02f4e3@suse.com \
    --to=nborisov@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.