xfs
[Top] [All Lists]

Re: [PATCH v3 17/20] xfsprogs/repair: helpers for finding in-core inode

To: Brian Foster <bfoster@xxxxxxxxxx>
Subject: Re: [PATCH v3 17/20] xfsprogs/repair: helpers for finding in-core inode records w/ free inodes
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 23 Apr 2014 16:24:43 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1397146270-42993-18-git-send-email-bfoster@xxxxxxxxxx>
References: <1397146270-42993-1-git-send-email-bfoster@xxxxxxxxxx> <1397146270-42993-18-git-send-email-bfoster@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Apr 10, 2014 at 12:11:07PM -0400, Brian Foster wrote:
> Add the findfirst_free_inode_rec() and next_free_ino_rec() helpers
> to assist scanning the in-core inode records for records with at
> least one free inode. These will be used to determine what records
> are included in the free inode btree.
> 
> Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx>
> ---
>  repair/incore.h | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/repair/incore.h b/repair/incore.h
> index 5419884..5f8c188 100644
> --- a/repair/incore.h
> +++ b/repair/incore.h
> @@ -381,6 +381,33 @@ void                     
> clear_uncertain_ino_cache(xfs_agnumber_t agno);
>               ((ino_tree_node_t *) ((ino_node_ptr)->avl_node.avl_forw))
>  
>  /*
> + * finobt helpers
> + */
> +static inline ino_tree_node_t *
> +findfirst_free_inode_rec(xfs_agnumber_t agno)
> +{
> +     ino_tree_node_t *ino_rec;
> +
> +     ino_rec = findfirst_inode_rec(agno);
> +
> +     while (ino_rec && !ino_rec->ir_free)
> +             ino_rec = next_ino_rec(ino_rec);
> +
> +     return ino_rec;
> +}
> +
> +static inline ino_tree_node_t *
> +next_free_ino_rec(ino_tree_node_t *ino_rec)
> +{
> +     ino_rec = next_ino_rec(ino_rec);
> +
> +     while (ino_rec && !ino_rec->ir_free)
> +             ino_rec = next_ino_rec(ino_rec);
> +
> +     return ino_rec;
> +}

That looks a bit inefficient - walking the list of inode records to
find the next one with free inodes. Perhaps we woul dbe better
served by adding a new list for inode records with free entries and
walking that instead?

Iknow, it's a memory vs speed tradeoff, but if we've got millions of
inodes and very few free, the difference could be very significant.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>