Fix: btrfs_get_extent flags and compress_type changed in linux 6.8.0-rc1
authorKienan Stewart <kstewart@efficios.com>
Mon, 22 Jan 2024 18:13:36 +0000 (13:13 -0500)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 2 Feb 2024 21:48:43 +0000 (16:48 -0500)
commit0c9bc964a5835ddc9aac11313175e10aa3adf27c
treea6333b56119008cf2821ca79109394a720b4df2f
parenta24df612575746a5cf458eb766c054f07edd7bbd
Fix: btrfs_get_extent flags and compress_type changed in linux 6.8.0-rc1

See upstream commit:

    commit f86f7a75e2fb5fd7d31d00eab8a392f97ba42ce9
    Author: Filipe Manana <fdmanana@suse.com>
    Date:   Mon Dec 4 16:20:33 2023 +0000

        btrfs: use the flags of an extent map to identify the compression type

        Currently, in struct extent_map, we use an unsigned int (32 bits) to
        identify the compression type of an extent and an unsigned long (64 bits
        on a 64 bits platform, 32 bits otherwise) for flags. We are only using
        6 different flags, so an unsigned long is excessive and we can use flags
        to identify the compression type instead of using a dedicated 32 bits
        field.

        We can easily have tens or hundreds of thousands (or more) of extent maps
        on busy and large filesystems, specially with compression enabled or many
        or large files with tons of small extents. So it's convenient to have the
        extent_map structure as small as possible in order to use less memory.

        So remove the compression type field from struct extent_map, use flags
        to identify the compression type and shorten the flags field from an
        unsigned long to a u32. This saves 8 bytes (on 64 bits platforms) and
        reduces the size of the structure from 136 bytes down to 128 bytes, using
        now only two cache lines, and increases the number of extent maps we can
        have per 4K page from 30 to 32. By using a u32 for the flags instead of
        an unsigned long, we no longer use test_bit(), set_bit() and clear_bit(),
        but that level of atomicity is not needed as most flags are never cleared
        once set (before adding an extent map to the tree), and the ones that can
        be cleared or set after an extent map is added to the tree, are always
        performed while holding the write lock on the extent map tree, while the
        reader holds a lock on the tree or tests for a flag that never changes
        once the extent map is in the tree (such as compression flags).

Change-Id: I95402d43f064c016b423b48652e4968d3db9b8a9
Signed-off-by: Kienan Stewart <kstewart@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
include/instrumentation/events/btrfs.h
This page took 0.025675 seconds and 4 git commands to generate.