On 11.01.2018 08:59, Gu Jinxiang wrote:
> Use enum READA_FORWARD instead of integers value to keep source robust.
>
> Changelog:
> v2->v1: change enum from READA_BACK to READA_FORWARD, since according
> to the logic of the source, it should reada_for_search forward, not
> backward.
> And, Reference:
> commit e4058b54d1e4 ("btrfs: cleanup, use enum values for btrfs_path reada")
>
> Signed-off-by: Gu Jinxiang <g...@cn.fujitsu.com>
> ---
> fs/btrfs/free-space-tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/free-space-tree.c b/fs/btrfs/free-space-tree.c
> index fe5e0324dca9..af36a6a971fe 100644
> --- a/fs/btrfs/free-space-tree.c
> +++ b/fs/btrfs/free-space-tree.c
> @@ -1071,7 +1071,7 @@ static int populate_free_space_tree(struct
> btrfs_trans_handle *trans,
> path = btrfs_alloc_path();
> if (!path)
> return -ENOMEM;
> - path->reada = 1;
> + path->reada = READA_FORWARD;
So in btrfs_search_slot_for_read we can go either backwards to forward
based on the penultimate parameter (find_higher). We always pass that to
1 meaning we will be going iterating the leaves forward. In that regard
we do want READA_FORWARD. Perhaps you might want to put this explanation
in your commit message.
>
> path2 = btrfs_alloc_path();
> if (!path2) {
> @@ -1573,7 +1573,7 @@ int load_free_space_tree(struct btrfs_caching_control
> *caching_ctl)
> */
> path->skip_locking = 1;
> path->search_commit_root = 1;
> - path->reada = 1;
> + path->reada = READA_FORWARD;
Similar thing here. When we call load_free_space_bitmaps or
load_free_space_extents we would be calling btrfs_next_item so reading
forward makes sense.
>
> info = search_free_space_info(NULL, fs_info, block_group, path, 0);
> if (IS_ERR(info)) {
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
