All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3.1 1/9] btrfs: delayed-ref: Introduce better documented delayed ref structures
Date: Fri, 5 Apr 2019 14:09:50 +0200	[thread overview]
Message-ID: <20190405120950.GW29086@twin.jikos.cz> (raw)
In-Reply-To: <20190404064537.4031-2-wqu@suse.com>

On Thu, Apr 04, 2019 at 02:45:29PM +0800, Qu Wenruo wrote:
> Current delayed ref interface has several problems:
> - Longer and longer parameter lists
>   bytenr
>   num_bytes
>   parent
>   ---------- so far so good
>   ref_root
>   owner
>   offset
>   ---------- I don't feel good now
> 
> - Different interpretation for the same parameter
>   Above @owner for data ref is inode number (u64),
>   while for tree ref, it's level (int).
> 
>   They are even in different size range.
>   For level we only need 0~8, while for ino it's
>   BTRFS_FIRST_FREE_OBJECTID~BTRFS_LAST_FREE_OBJECTID.
> 
>   And @offset doesn't even makes sense for tree ref.
> 
>   Such parameter reuse may look clever as an hidden union, but it
>   destroys code readability.
> 
> To solve both problems, we introduce a new structure, btrfs_ref to solve
> them:
> 
> - Structure instead of long parameter list
>   This makes later expansion easier, and better documented.
> 
> - Use btrfs_ref::type to distinguish data and tree ref
> 
> - Use proper union to store data/tree ref specific structures.
> 
> - Use separate functions to fill data/tree ref data, with a common generic
>   function to fill common bytenr/num_bytes members.
> 
> All parameters will find its place in btrfs_ref, and an extra member,
> @real_root, inspired by ref-verify code, is newly introduced for later
> qgroup code, to record which tree is triggered this extent modification.
> 
> This patch doesn't touch any code, but provides the basis for incoming
> refactors.
> 
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>  fs/btrfs/delayed-ref.h | 116 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 116 insertions(+)
> 
> diff --git a/fs/btrfs/delayed-ref.h b/fs/btrfs/delayed-ref.h
> index 70606da440aa..8eb5b3576759 100644
> --- a/fs/btrfs/delayed-ref.h
> +++ b/fs/btrfs/delayed-ref.h
> @@ -176,6 +176,90 @@ struct btrfs_delayed_ref_root {
>  	u64 qgroup_to_skip;
>  };
>  
> +enum btrfs_ref_type {
> +	BTRFS_REF_NOT_SET,
> +	BTRFS_REF_DATA,
> +	BTRFS_REF_METADATA,
> +	BTRFS_REF_LAST,
> +};
> +
> +struct btrfs_data_ref {
> +	/* For EXTENT_DATA_REF */
> +
> +	/* Root who refers to this data extent */
> +	u64 ref_root;
> +
> +	/* Inode who refers to this data extent */
> +	u64 ino;
> +
> +	/*
> +	 * file_offset - extent_offset
> +	 *
> +	 * file_offset is the key.offset of the EXTENT_DATA key.
> +	 * extent_offset is btrfs_file_extent_offset() of the EXTENT_DATA data.
> +	 */
> +	u64 offset;
> +};
> +
> +struct btrfs_tree_ref {
> +	/*
> +	 * Level of this tree block
> +	 *
> +	 * Shared for skinny (TREE_BLOCK_REF) and normal tree ref.
> +	 */
> +	int level;
> +
> +	/*
> +	 * Root who refers to this tree block.
> +	 *
> +	 * For TREE_BLOCK_REF (skinny metadata, either inline or keyed)
> +	 */
> +	u64 root;
> +
> +	/* For non-skinny metadata, no special member needed */
> +};
> +
> +struct btrfs_ref {

The structure name sounds a bit generic, but I think we can keep it
short. There are no other btrfs-specific references that could be
confused, there are 'backrefs', 'delayed-refs' all refering to the
b-tree references.

> +	enum btrfs_ref_type type;
> +	int action;
> +
> +	/*
> +	 * Only use parent pointers as backref (SHARED_BLOCK_REF or
> +	 * SHARED_DATA_REF) for this extent and its children.
> +	 * Set for reloc trees.
> +	 */
> +	bool only_backreferences:1;

No bool bitfields please, wasn't this mentioned last time?

  reply	other threads:[~2019-04-05 12:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  6:45 [PATCH v3.1 0/9] btrfs: Refactor delayed ref parameter list Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 1/9] btrfs: delayed-ref: Introduce better documented delayed ref structures Qu Wenruo
2019-04-05 12:09   ` David Sterba [this message]
2019-04-05 13:18     ` Qu Wenruo
2019-04-05 15:51       ` David Sterba
2019-04-05 23:47         ` Qu Wenruo
2019-04-06  6:21           ` Nikolay Borisov
2019-04-12 15:46   ` David Sterba
2019-04-12 23:48     ` Qu Wenruo
2019-04-15 16:50       ` David Sterba
2019-04-16  0:01         ` Qu Wenruo
2019-04-17 13:35           ` David Sterba
2019-04-04  6:45 ` [PATCH v3.1 2/9] btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 3/9] btrfs: delayed-ref: Use btrfs_ref to refactor btrfs_add_delayed_tree_ref() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 4/9] btrfs: delayed-ref: Use btrfs_ref to refactor btrfs_add_delayed_data_ref() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 5/9] btrfs: ref-verify: Use btrfs_ref to refactor btrfs_ref_tree_mod() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 6/9] btrfs: extent-tree: Use btrfs_ref to refactor add_pinned_bytes() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 7/9] btrfs: extent-tree: Use btrfs_ref to refactor btrfs_inc_extent_ref() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 8/9] btrfs: extent-tree: Use btrfs_ref to refactor btrfs_free_extent() Qu Wenruo
2019-04-04  6:45 ` [PATCH v3.1 9/9] btrfs: qgroup: Don't scan leaf if we're modifying reloc tree Qu Wenruo
2019-04-05 12:06 ` [PATCH v3.1 0/9] btrfs: Refactor delayed ref parameter list David Sterba
2019-04-23 11:42   ` 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=20190405120950.GW29086@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --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.