aboutsummaryrefslogtreecommitdiff
path: root/fs/btrfs/extent_map.h
diff options
context:
space:
mode:
authorGravatar Filipe Manana <fdmanana@suse.com> 2023-11-21 13:38:38 +0000
committerGravatar David Sterba <dsterba@suse.com> 2023-12-15 20:27:02 +0100
commit7dc66abb5a47778d7db327783a0ba172b8cff0b5 (patch)
tree66fef581a2f31904aae1c15f9fdbbc7aec798132 /fs/btrfs/extent_map.h
parentbtrfs: use btrfs_next_item() at scrub.c:find_first_extent_item() (diff)
downloadlinux-7dc66abb5a47778d7db327783a0ba172b8cff0b5.tar.gz
linux-7dc66abb5a47778d7db327783a0ba172b8cff0b5.tar.bz2
linux-7dc66abb5a47778d7db327783a0ba172b8cff0b5.zip
btrfs: use a dedicated data structure for chunk maps
Currently we abuse the extent_map structure for two purposes: 1) To actually represent extents for inodes; 2) To represent chunk mappings. This is odd and has several disadvantages: 1) To create a chunk map, we need to do two memory allocations: one for an extent_map structure and another one for a map_lookup structure, so more potential for an allocation failure and more complicated code to manage and link two structures; 2) For a chunk map we actually only use 3 fields (24 bytes) of the respective extent map structure: the 'start' field to have the logical start address of the chunk, the 'len' field to have the chunk's size, and the 'orig_block_len' field to contain the chunk's stripe size. Besides wasting a memory, it's also odd and not intuitive at all to have the stripe size in a field named 'orig_block_len'. We are also using 'block_len' of the extent_map structure to contain the chunk size, so we have 2 fields for the same value, 'len' and 'block_len', which is pointless; 3) When an extent map is associated to a chunk mapping, we set the bit EXTENT_FLAG_FS_MAPPING on its flags and then make its member named 'map_lookup' point to the associated map_lookup structure. This means that for an extent map associated to an inode extent, we are not using this 'map_lookup' pointer, so wasting 8 bytes (on a 64 bits platform); 4) Extent maps associated to a chunk mapping are never merged or split so it's pointless to use the existing extent map infrastructure. So add a dedicated data structure named 'btrfs_chunk_map' to represent chunk mappings, this is basically the existing map_lookup structure with some extra fields: 1) 'start' to contain the chunk logical address; 2) 'chunk_len' to contain the chunk's length; 3) 'stripe_size' for the stripe size; 4) 'rb_node' for insertion into a rb tree; 5) 'refs' for reference counting. This way we do a single memory allocation for chunk mappings and we don't waste memory for them with unused/unnecessary fields from an extent_map. We also save 8 bytes from the extent_map structure by removing the 'map_lookup' pointer, so the size of struct extent_map is reduced from 144 bytes down to 136 bytes, and we can now have 30 extents map per 4K page instead of 28. Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/extent_map.h')
-rw-r--r--fs/btrfs/extent_map.h4
1 files changed, 0 insertions, 4 deletions
diff --git a/fs/btrfs/extent_map.h b/fs/btrfs/extent_map.h
index d0328127f89c..bae14af197ef 100644
--- a/fs/btrfs/extent_map.h
+++ b/fs/btrfs/extent_map.h
@@ -23,8 +23,6 @@ enum {
EXTENT_FLAG_LOGGING,
/* Filling in a preallocated extent */
EXTENT_FLAG_FILLING,
- /* filesystem extent mapping type */
- EXTENT_FLAG_FS_MAPPING,
/* This em is merged from two or more physically adjacent ems */
EXTENT_FLAG_MERGED,
};
@@ -50,8 +48,6 @@ struct extent_map {
*/
u64 generation;
unsigned long flags;
- /* Used for chunk mappings, flag EXTENT_FLAG_FS_MAPPING must be set */
- struct map_lookup *map_lookup;
refcount_t refs;
unsigned int compress_type;
struct list_head list;