kernel.git/fs/btrfs/tests/inode-tests.c, branch master

btrfs: tests: remove invalid file extent map tests

2026-02-03T06:56:19Z

In the inode self tests, there are several problems: - Invalid file extents E.g. hole range [4K, 4K + 4) is completely invalid. Only inlined extent maps can have an unaligned ram_bytes, and even for that case, the generated extent map will use sectorsize as em->len. - Unaligned hole after inlined extent The kernel never does this by itself, the current btrfs_get_extent() will only return a single inlined extent map that covers the first block. - Incorrect numbers in the comment E.g. 12291 no matter if you add or dec 1, is not aligned to 4K. The properly number for 12K is 12288, I don't know why there is even a diff of 3, and this completely doesn't match the extent map we inserted later. - Hard-to-modify sequence in setup_file_extents() If some unfortunate person, just like me, needs to modify setup_file_extents(), good luck not screwing up the file offset. Fix them by: - Remove invalid unaligned extent maps This mostly means remove the [4K, 4K + 4) hole case. The remaining ones are already properly aligned. This slightly changes the on-disk data extent allocation, with that removed, the regular extents at [4K, 8K) and [8K , 12K) can be merged. So also add a 4K gap between those two data extents to prevent em merge. - Remove the implied hole after an inlined extent Just like what the kernel is doing for inlined extents in the real world. - Update the commit using proper numbers with 'K' suffixes Since there is no unaligned range except the first inlined one, we can always use numbers with 'K' suffixes, which is way more easier to read, and will always be aligned to 1024 at least. - Add comments in setup_file_extents() So that we're clear about the file offset for each test file extent. Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba

btrfs: use the btrfs_extent_map_end() helper everywhere

2026-02-03T06:54:36Z

We have a helper to calculate an extent map's exclusive end offset, but we only use it in some places. Update every site that open codes the calculation to use the helper. Reviewed-by: Johannes Thumshirn Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: remove btrfs_clear_extent_bits()

2025-07-21T22:09:22Z

It's just a simple wrapper around btrfs_clear_extent_bit() that passes a NULL for its last argument (a cached extent state record), plus there is not counter part - we have a btrfs_set_extent_bit() but we do not have a btrfs_set_extent_bits() (plural version). So just remove it and make all callers use btrfs_clear_extent_bit() directly. Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: rename functions to allocate and free extent maps

2025-05-15T12:30:45Z

These functions are exported and don't have a 'btrfs_' prefix in their names, which goes against coding style conventions. Rename them to have such prefix, making it clear they are from btrfs and avoiding potential collisions in the future with functions defined elsewhere outside btrfs. Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: rename extent map functions to get block start, end and check if in tree

2025-05-15T12:30:45Z

btrfs: rename exported extent map compression functions

2025-05-15T12:30:45Z

btrfs: rename the functions to clear bits for an extent range

2025-05-15T12:30:43Z

These functions are exported so they should have a 'btrfs_' prefix by convention, to make it clear they are btrfs specific and to avoid collisions with functions from elsewhere in the kernel. One of them has a double underscore prefix which is also discouraged. So remove double underscore prefix where applicable and add a 'btrfs_' prefix to their name to make it clear they are from btrfs. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: use clear_extent_bits() instead of clear_extent_bit() where possible

2025-05-15T12:30:41Z

Several places are using clear_extent_bit() and passing a NULL value for the 'cached' argument, which is pointless as they can use instead clear_extent_bits(). Reviewed-by: Boris Burkov Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: remove leftover EXTENT_UPTODATE clear from an inode's io_tree

2025-05-15T12:30:39Z

After commit 52b029f42751 ("btrfs: remove unnecessary EXTENT_UPTODATE state in buffered I/O path") we never set EXTENT_UPTODATE in an inode's io_tree anymore, but we still have some code attempting to clear that bit from an inode's io_tree. Remove that code as it doesn't do anything anymore. The sole use of the EXTENT_UPTODATE bit is for the excluded extents io_tree (fs_info->excluded_extents), which is used to track the locations of super blocks, so that their ranges are never marked as free, making them unavailable for extent allocation. Reviewed-by: Boris Burkov Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba

btrfs: remove extent_map::block_start member

2024-07-11T13:33:21Z

The member extent_map::block_start can be calculated from extent_map::disk_bytenr + extent_map::offset for regular extents. And otherwise just extent_map::disk_bytenr. And this is already validated by the validate_extent_map(). Now we can remove the member. However there is a special case in btrfs_create_dio_extent() where we for NOCOW/PREALLOC ordered extents cannot directly use the resulting btrfs_file_extent, as btrfs_split_ordered_extent() cannot handle them yet. So for that call site, we pass file_extent->disk_bytenr + file_extent->num_bytes as disk_bytenr for the ordered extent, and 0 for offset. Reviewed-by: Johannes Thumshirn Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba