Just like what we do in kernel, since we will not support different
leaf/node/stripe size per tree, there is no need to store these block
sizes in btrfs_root.

This patch will introduce these block size members into btrfs_fs_info
structure, allowing us to convert such usage in later patches.

Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com>
---
 chunk-recover.c | 3 +++
 ctree.h         | 4 ++++
 disk-io.c       | 3 +++
 3 files changed, 10 insertions(+)

diff --git a/chunk-recover.c b/chunk-recover.c
index cf8b3184..1a880038 100644
--- a/chunk-recover.c
+++ b/chunk-recover.c
@@ -1475,6 +1475,9 @@ open_ctree_with_broken_chunk(struct recover_control *rc)
        }
 
        memcpy(fs_info->fsid, &disk_super->fsid, BTRFS_FSID_SIZE);
+       fs_info->sectorsize = btrfs_super_sectorsize(disk_super);
+       fs_info->nodesize = btrfs_super_nodesize(disk_super);
+       fs_info->stripesize = btrfs_super_stripesize(disk_super);
 
        ret = btrfs_check_fs_compatibility(disk_super, OPEN_CTREE_WRITES);
        if (ret)
diff --git a/ctree.h b/ctree.h
index c457a8dc..78956a4f 100644
--- a/ctree.h
+++ b/ctree.h
@@ -1147,6 +1147,10 @@ struct btrfs_fs_info {
        struct cache_tree *fsck_extent_cache;
        struct cache_tree *corrupt_blocks;
 
+       /* Cached block sizes */
+       u32 nodesize;
+       u32 sectorsize;
+       u32 stripesize;
 };
 
 /*
diff --git a/disk-io.c b/disk-io.c
index 838d5cd4..bfdac5ab 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -1327,6 +1327,9 @@ static struct btrfs_fs_info *__open_ctree_fd(int fp, 
const char *path,
        }
 
        memcpy(fs_info->fsid, &disk_super->fsid, BTRFS_FSID_SIZE);
+       fs_info->sectorsize = btrfs_super_sectorsize(disk_super);
+       fs_info->nodesize = btrfs_super_nodesize(disk_super);
+       fs_info->stripesize = btrfs_super_stripesize(disk_super);
 
        ret = btrfs_check_fs_compatibility(fs_info->super_copy, flags);
        if (ret)
-- 
2.13.0



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