btrfs: tests: remove invalid file extent map tests

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 <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>

0 files changed, 0 insertions, 0 deletions