Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 01/10] Btrfs: add helper for em merge logic
Date: Fri, 22 Dec 2017 10:45:09 -0800	[thread overview]
Message-ID: <20171222184508.GA21643@lim.localdomain> (raw)
In-Reply-To: <e6987bab-a88c-3e6a-13b5-c05f73e53b71@suse.com>

On Fri, Dec 22, 2017 at 09:23:40AM +0200, Nikolay Borisov wrote:
> 
> 
> On 22.12.2017 00:42, Liu Bo wrote:
> > This is a prepare work for the following extent map selftest, which
> > runs tests against em merge logic.
> > 
> > Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
> > ---
> >  fs/btrfs/ctree.h |   2 ++
> >  fs/btrfs/inode.c | 101 ++++++++++++++++++++++++++++++-------------------------
> >  2 files changed, 58 insertions(+), 45 deletions(-)
> > 
> > diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> > index b2e09fe..328f40f 100644
> > --- a/fs/btrfs/ctree.h
> > +++ b/fs/btrfs/ctree.h
> > @@ -3148,6 +3148,8 @@ struct btrfs_delalloc_work *btrfs_alloc_delalloc_work(struct inode *inode,
> >  						    int delay_iput);
> >  void btrfs_wait_and_free_delalloc_work(struct btrfs_delalloc_work *work);
> >  
> > +int btrfs_add_extent_mapping(struct extent_map_tree *em_tree,
> > +			     struct extent_map **em_in, u64 start, u64 len);
> >  struct extent_map *btrfs_get_extent_fiemap(struct btrfs_inode *inode,
> >  		struct page *page, size_t pg_offset, u64 start,
> >  		u64 len, int create);
> > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > index e1a7f3c..527df6f 100644
> > --- a/fs/btrfs/inode.c
> > +++ b/fs/btrfs/inode.c
> > @@ -6911,6 +6911,61 @@ static noinline int uncompress_inline(struct btrfs_path *path,
> >  	return ret;
> >  }
> >  
> > +int btrfs_add_extent_mapping(struct extent_map_tree *em_tree,
> > +			     struct extent_map **em_in, u64 start, u64 len)
> 
> How about adding the following comment above the function: 
> 
> /**                                                                             
>  * btrfs_add_extent_mapping - try to add given extent mapping                   
>  * @em_tree - the extent tree into which we want to add the mapping             
>  * @em_in - extent we are inserting                                             
>  * @start - the start of the logical range of the extent we are adding          
>  * @len - logical length of the extent                                          
>  *                                                                              
>  * Insert @em_in into @em_tree. In case there is an overlapping range, handle   
>  * the -EEXIST by either:                                                       
>  * a) Returning the existing extent in @em_in if there is a full overlap        
>  * b) Merge the extents if they are near each other.                            
>  *                                                                              
>  * Returns 0 on success or a negative error code                               
>  *                                                                              
>  */ 
> 

Appreciate your comments.

Sure, comments are always welcome.

> Also one thing which I'm not very clear is why do we need the start/len, aren't 
> those already set in em_in ?
>

[start, start+len) is within *em_in, ie.

|----*em_in--------|
   |------|
  start   start+len

What we really care about is [start, start+len), which is passed to
btrfs_get_extent().

For example, if a file extent item on disk is [0, 32k), given a tuple
(start=0, len=4k), reading [0, 4k) would end up with *em_in being
[0, 32k).

So if add_extent_mapping(*em_in) returns EEXIST, then we know the
'existing' em is overlapped with *em_in, then we need to check whether
it's overlapped with [start, start+len).

thanks,
-liubo

> 
> 
> > +{
> > +	int ret;
> > +	struct extent_map *em = *em_in;
> > +
> > +	ret = add_extent_mapping(em_tree, em, 0);
> > +	/* it is possible that someone inserted the extent into the tree
> > +	 * while we had the lock dropped.  It is also possible that
> > +	 * an overlapping map exists in the tree
> > +	 */
> > +	if (ret == -EEXIST) {
> > +		struct extent_map *existing;
> > +
> > +		ret = 0;
> > +
> > +		existing = search_extent_mapping(em_tree, start, len);
> > +
> > +		/*
> > +		 * existing will always be non-NULL, since there must be
> > +		 * extent causing the -EEXIST.
> > +		 */
> > +		if (existing->start == em->start &&
> > +		    extent_map_end(existing) >= extent_map_end(em) &&
> > +		    em->block_start == existing->block_start) {
> > +			/*
> > +			 * The existing extent map already encompasses the
> > +			 * entire extent map we tried to add.
> > +			 */
> > +			free_extent_map(em);
> > +			*em_in = existing;
> > +			ret = 0;
> > +		} else if (start >= extent_map_end(existing) ||
> > +		    start <= existing->start) {
> > +			/*
> > +			 * The existing extent map is the one nearest to
> > +			 * the [start, start + len) range which overlaps
> > +			 */
> > +			ret = merge_extent_mapping(em_tree, existing,
> > +						   em, start);
> > +			free_extent_map(existing);
> > +			if (ret) {
> > +				free_extent_map(em);
> > +				*em_in = NULL;
> > +			}
> > +		} else {
> > +			free_extent_map(em);
> > +			*em_in = existing;
> > +			ret = 0;
> > +		}
> > +	}
> > +	ASSERT(ret == 0 || ret == -EEXIST);
> > +	return ret;
> > +}
> > +
> >  /*
> >   * a bit scary, this does extent mapping from logical file offset to the disk.
> >   * the ugly parts come from merging extents from the disk with the in-ram
> > @@ -7147,51 +7202,7 @@ struct extent_map *btrfs_get_extent(struct btrfs_inode *inode,
> >  
> >  	err = 0;
> >  	write_lock(&em_tree->lock);
> > -	ret = add_extent_mapping(em_tree, em, 0);
> > -	/* it is possible that someone inserted the extent into the tree
> > -	 * while we had the lock dropped.  It is also possible that
> > -	 * an overlapping map exists in the tree
> > -	 */
> > -	if (ret == -EEXIST) {
> > -		struct extent_map *existing;
> > -
> > -		ret = 0;
> > -
> > -		existing = search_extent_mapping(em_tree, start, len);
> > -		/*
> > -		 * existing will always be non-NULL, since there must be
> > -		 * extent causing the -EEXIST.
> > -		 */
> > -		if (existing->start == em->start &&
> > -		    extent_map_end(existing) >= extent_map_end(em) &&
> > -		    em->block_start == existing->block_start) {
> > -			/*
> > -			 * The existing extent map already encompasses the
> > -			 * entire extent map we tried to add.
> > -			 */
> > -			free_extent_map(em);
> > -			em = existing;
> > -			err = 0;
> > -
> > -		} else if (start >= extent_map_end(existing) ||
> > -		    start <= existing->start) {
> > -			/*
> > -			 * The existing extent map is the one nearest to
> > -			 * the [start, start + len) range which overlaps
> > -			 */
> > -			err = merge_extent_mapping(em_tree, existing,
> > -						   em, start);
> > -			free_extent_map(existing);
> > -			if (err) {
> > -				free_extent_map(em);
> > -				em = NULL;
> > -			}
> > -		} else {
> > -			free_extent_map(em);
> > -			em = existing;
> > -			err = 0;
> > -		}
> > -	}
> > +	err = btrfs_add_extent_mapping(em_tree, &em, start, len);
> >  	write_unlock(&em_tree->lock);
> >  out:
> >  
> > 

  reply	other threads:[~2017-12-22 18:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-21 22:42 [PATCH 00/10] bugfixes and regression tests of btrfs_get_extent Liu Bo
2017-12-21 22:42 ` [PATCH 01/10] Btrfs: add helper for em merge logic Liu Bo
2017-12-22  7:23   ` Nikolay Borisov
2017-12-22 18:45     ` Liu Bo [this message]
2017-12-21 22:42 ` [PATCH 02/10] Btrfs: move extent map specific code to extent_map.c Liu Bo
2017-12-21 22:42 ` [PATCH 03/10] Btrfs: add extent map selftests Liu Bo
2017-12-22  7:42   ` Nikolay Borisov
2017-12-22 18:53     ` Liu Bo
2017-12-21 22:42 ` [PATCH 04/10] Btrfs: extent map selftest: buffered write vs dio read Liu Bo
2017-12-22  7:51   ` Nikolay Borisov
2017-12-22 18:58     ` Liu Bo
2017-12-21 22:42 ` [PATCH 05/10] Btrfs: extent map selftest: dio " Liu Bo
2017-12-21 22:42 ` [PATCH 06/10] Btrfs: fix incorrect block_len in merge_extent_mapping Liu Bo
2017-12-21 22:42 ` [PATCH 07/10] Btrfs: fix unexpected EEXIST from btrfs_get_extent Liu Bo
2017-12-22 12:10   ` Nikolay Borisov
2017-12-22 19:19     ` Liu Bo
2017-12-21 22:42 ` [PATCH 08/10] Btrfs: add WARN_ONCE to detect unexpected error from merge_extent_mapping Liu Bo
2017-12-22  8:52   ` Nikolay Borisov
2017-12-21 22:42 ` [PATCH 09/10] Btrfs: add tracepoint for em's EEXIST case Liu Bo
2017-12-22  8:56   ` Nikolay Borisov
2017-12-22 19:07     ` Liu Bo
2017-12-23  7:39       ` Nikolay Borisov
2018-01-02 18:02         ` Liu Bo
2017-12-21 22:42 ` [PATCH 10/10] Btrfs: noinline merge_extent_mapping Liu Bo

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=20171222184508.GA21643@lim.localdomain \
    --to=bo.li.liu@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox