linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arne Jansen <sensille@gmx.net>
To: Ilya Dryomov <idryomov@gmail.com>
Cc: linux-btrfs@vger.kernel.org, Chris Mason <chris.mason@oracle.com>,
	Hugo Mills <hugo@carfax.org.uk>
Subject: Re: [PATCH 03/21] Btrfs: add BTRFS_AVAIL_ALLOC_BIT_SINGLE bit
Date: Tue, 01 Nov 2011 08:56:23 +0100	[thread overview]
Message-ID: <4EAFA627.6080505@gmx.net> (raw)
In-Reply-To: <1314129722-31601-4-git-send-email-idryomov@gmail.com>

On 23.08.2011 22:01, Ilya Dryomov wrote:
> Right now on-disk BTRFS_BLOCK_GROUP_* profile bits are used for
> avail_{data,metadata,system}_alloc_bits fields, which are there to tell
> us about available allocation profiles in the fs.  When chunk is
> created, it's profile is OR'ed with respective avail_alloc_bits field.
> Since SINGLE is denoted by 0 in the on-disk format, currently there is
> no way to tell when such chunks become avaialble.  Restriper needs that
> information, so add a separate bit for SINGLE profile.
> 
> This bit is going to be in-memory only, it should never be written out
> to disk, so it's not a disk format change.  However to avoid remappings
> in future, reserve corresponding on-disk bit.
> 
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
>  fs/btrfs/ctree.h       |   12 ++++++++++++
>  fs/btrfs/extent-tree.c |   22 ++++++++++++++--------
>  2 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index b882c95..5b00eb8 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -725,6 +725,17 @@ struct btrfs_csum_item {
>  					 BTRFS_BLOCK_GROUP_RAID1 |   \
>  					 BTRFS_BLOCK_GROUP_DUP |     \
>  					 BTRFS_BLOCK_GROUP_RAID10)
> +/*
> + * We need a bit for restriper to be able to tell when chunks of type
> + * SINGLE are available.  It is used in avail_*_alloc_bits.
> + */
> +#define BTRFS_AVAIL_ALLOC_BIT_SINGLE (1 << 7)
> +
> +/*
> + * To avoid troubles or remappings, reserve on-disk bit.
> + */
> +#define BTRFS_BLOCK_GROUP_RESERVED   (1 << 7)

can you move this define up to where the other BLOCK_GROUPS are defined?
Otherwise it is easy to overlook.

> +
>  struct btrfs_block_group_item {
>  	__le64 used;
>  	__le64 chunk_objectid;
> @@ -1100,6 +1111,7 @@ struct btrfs_fs_info {
>  	spinlock_t ref_cache_lock;
>  	u64 total_ref_cache_size;
>  
> +	/* SINGLE has it's own bit for these three */

While this comment is easily understandable in the context in this patch,
it is not enough when just reading the resulting code without the commit
message. It would be good if you could duplicate more of the commit message
into code comments.

>  	u64 avail_data_alloc_bits;
>  	u64 avail_metadata_alloc_bits;
>  	u64 avail_system_alloc_bits;
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index de4c639..ed35eb5 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -2945,14 +2945,17 @@ static int update_space_info(struct btrfs_fs_info *info, u64 flags,
>  static void set_avail_alloc_bits(struct btrfs_fs_info *fs_info, u64 flags)
>  {
>  	u64 extra_flags = flags & BTRFS_BLOCK_GROUP_PROFILE_MASK;
> -	if (extra_flags) {
> -		if (flags & BTRFS_BLOCK_GROUP_DATA)
> -			fs_info->avail_data_alloc_bits |= extra_flags;
> -		if (flags & BTRFS_BLOCK_GROUP_METADATA)
> -			fs_info->avail_metadata_alloc_bits |= extra_flags;
> -		if (flags & BTRFS_BLOCK_GROUP_SYSTEM)
> -			fs_info->avail_system_alloc_bits |= extra_flags;
> -	}
> +
> +	/* on-disk -> in-memory */
> +	if (extra_flags == 0)
> +		extra_flags = BTRFS_AVAIL_ALLOC_BIT_SINGLE;
> +
> +	if (flags & BTRFS_BLOCK_GROUP_DATA)
> +		fs_info->avail_data_alloc_bits |= extra_flags;
> +	if (flags & BTRFS_BLOCK_GROUP_METADATA)
> +		fs_info->avail_metadata_alloc_bits |= extra_flags;
> +	if (flags & BTRFS_BLOCK_GROUP_SYSTEM)
> +		fs_info->avail_system_alloc_bits |= extra_flags;
>  }
>  
>  u64 btrfs_reduce_alloc_profile(struct btrfs_root *root, u64 flags)
> @@ -2986,6 +2989,9 @@ u64 btrfs_reduce_alloc_profile(struct btrfs_root *root, u64 flags)
>  	     (flags & BTRFS_BLOCK_GROUP_RAID10) |
>  	     (flags & BTRFS_BLOCK_GROUP_DUP)))
>  		flags &= ~BTRFS_BLOCK_GROUP_RAID0;
> +
> +	/* in-memory -> on-disk */
> +	flags &= ~BTRFS_AVAIL_ALLOC_BIT_SINGLE;
>  	return flags;
>  }
>  


  reply	other threads:[~2011-11-01  7:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-23 20:01 [PATCH 00/21] [RFC] Btrfs: restriper Ilya Dryomov
2011-08-23 20:01 ` [PATCH 01/21] Btrfs: get rid of *_alloc_profile fields Ilya Dryomov
2011-09-27 12:51   ` David Sterba
2011-08-23 20:01 ` [PATCH 02/21] Btrfs: introduce masks for chunk type and profile Ilya Dryomov
2011-08-23 20:01 ` [PATCH 03/21] Btrfs: add BTRFS_AVAIL_ALLOC_BIT_SINGLE bit Ilya Dryomov
2011-11-01  7:56   ` Arne Jansen [this message]
2011-08-23 20:01 ` [PATCH 04/21] Btrfs: make avail_*_alloc_bits fields dynamic Ilya Dryomov
2011-08-23 20:01 ` [PATCH 05/21] Btrfs: add basic restriper infrastructure Ilya Dryomov
2011-11-01 10:08   ` Arne Jansen
2011-11-01 11:07     ` David Sterba
2011-11-01 11:08       ` Arne Jansen
2011-08-23 20:01 ` [PATCH 06/21] Btrfs: implement online profile changing Ilya Dryomov
2011-08-23 20:01 ` [PATCH 07/21] Btrfs: add basic infrastructure for selective balancing Ilya Dryomov
2011-09-27 13:02   ` David Sterba
2011-09-27 17:28     ` Ilya Dryomov
2011-08-23 20:01 ` [PATCH 08/21] Btrfs: soft profile changing mode (aka soft convert) Ilya Dryomov
2011-08-23 20:01 ` [PATCH 09/21] Btrfs: profiles filter Ilya Dryomov
2011-08-23 20:01 ` [PATCH 10/21] Btrfs: usage filter Ilya Dryomov
2011-09-27 13:22   ` David Sterba
2011-11-01 10:18   ` Arne Jansen
2011-08-23 20:01 ` [PATCH 11/21] Btrfs: devid filter Ilya Dryomov
2011-08-23 20:01 ` [PATCH 12/21] Btrfs: devid subset filter Ilya Dryomov
2011-08-23 20:01 ` [PATCH 13/21] Btrfs: virtual address space " Ilya Dryomov
2011-08-23 20:01 ` [PATCH 14/21] Btrfs: save restripe parameters to disk Ilya Dryomov
2011-09-27 13:43   ` David Sterba
2011-11-01 10:29   ` Arne Jansen
2011-08-23 20:01 ` [PATCH 15/21] Btrfs: recover restripe on mount Ilya Dryomov
2011-11-01 10:57   ` Arne Jansen
2011-08-23 20:01 ` [PATCH 16/21] Btrfs: allow for cancelling restriper Ilya Dryomov
2011-08-23 20:01 ` [PATCH 17/21] Btrfs: allow for pausing restriper Ilya Dryomov
2011-11-01 11:46   ` Arne Jansen
2011-08-23 20:01 ` [PATCH 18/21] Btrfs: allow for resuming restriper after it was paused Ilya Dryomov
2011-08-23 20:02 ` [PATCH 19/21] Btrfs: add skip_restripe mount option Ilya Dryomov
2011-08-23 20:02 ` [PATCH 20/21] Btrfs: get rid of btrfs_balance() function Ilya Dryomov
2011-08-23 20:02 ` [PATCH 21/21] Btrfs: add restripe progress reporting Ilya Dryomov
2011-09-27 12:47 ` [PATCH 00/21] [RFC] Btrfs: restriper David Sterba
2011-11-14 23:59 ` Phillip Susi
2011-11-15  9:22   ` Ilya Dryomov
2011-11-15 14:33     ` Phillip Susi
2011-11-15 15:06       ` Ilya Dryomov
2011-11-17  3:13 ` Phillip Susi
  -- strict thread matches above, loose matches on Subject: below --
2012-01-06 14:30 [PATCH 00/21] " Ilya Dryomov
2012-01-06 14:30 ` [PATCH 03/21] Btrfs: add BTRFS_AVAIL_ALLOC_BIT_SINGLE bit Ilya Dryomov

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=4EAFA627.6080505@gmx.net \
    --to=sensille@gmx.net \
    --cc=chris.mason@oracle.com \
    --cc=hugo@carfax.org.uk \
    --cc=idryomov@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).