At 02/18/2017 09:28 AM, Liu Bo wrote:
With this, we can avoid allocating memory for dev replace copies if the
target dev is not available.

The patch itself looks good.

Reviewed-by: Qu Wenruo <quwen...@cn.fujitsu.com>

However I'm just curious about in which case we can have btrfs_dev_replace_is_going() returning 1 while dev_replace.tgtdev is NULL.

Since we are under the protect of btrfs_dev_replace_lock(), I wonder if dev_replace->tgt/srcdev can be modified.

Thanks,
Qu


Signed-off-by: Liu Bo <bo.li....@oracle.com>
---
 fs/btrfs/volumes.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index c434489..bcd44eb 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -5153,7 +5153,8 @@ int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 
logical, u64 len)
        free_extent_map(em);

        btrfs_dev_replace_lock(&fs_info->dev_replace, 0);
-       if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace))
+       if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace) &&
+           fs_info->dev_replace.tgtdev)
                ret++;
        btrfs_dev_replace_unlock(&fs_info->dev_replace, 0);

@@ -5858,7 +5859,7 @@ static int __btrfs_map_block(struct btrfs_fs_info 
*fs_info,
        }

        num_alloc_stripes = num_stripes;
-       if (dev_replace_is_ongoing) {
+       if (dev_replace_is_ongoing && dev_replace->tgtdev != NULL) {
                if (op == BTRFS_MAP_WRITE)
                        num_alloc_stripes <<= 1;
                if (op == BTRFS_MAP_GET_READ_MIRRORS)
@@ -5871,7 +5872,7 @@ static int __btrfs_map_block(struct btrfs_fs_info 
*fs_info,
                ret = -ENOMEM;
                goto out;
        }
-       if (dev_replace_is_ongoing)
+       if (dev_replace_is_ongoing && dev_replace->tgtdev != NULL)
                bbio->tgtdev_map = (int *)(bbio->stripes + num_alloc_stripes);

        /* build raid_map */



--
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

Reply via email to