Skip to content

tests assume 4KiB filesystem allocation granularity #13716

Description

@adrianEffe

Several tests appear to assume a 4 KiB filesystem allocation granularity.
The commands themselves appear to behave correctly.

I encountered 11 test failures while running the test suite on AArch64 (Kernel: 6.19.14-400.asahi.fc42.aarch64+16k) with 16 KiB base pages.

The failing tests are:

failures:
    test_cp::test_cp_debug_default_with_hole
    test_cp::test_cp_debug_reflink_never_file_with_hole
    test_cp::test_cp_debug_reflink_never_sparse_always_with_hole
    test_cp::test_cp_debug_reflink_never_with_hole
    test_cp::test_cp_debug_sparse_never_file_with_hole
    test_du::test_du_symlink_multiple_fail
    test_ls::test_ls_block_size_override
    test_ls::test_ls_invalid_block_size_in_env_var
    test_ls::test_ls_long_total_size
    test_ls::test_posixly_correct_and_block_size_env_vars
    test_ls::test_posixly_correct_and_block_size_env_vars_with_k

The five cp tests for instance expect SEEK_HOLE sparse detection, but the fixture in this case is hardcoded to 10_000 bytes. When appending data it can create a visible hole on a 4 KiB filesystem but on a 16 KiB filesystem that offset is still within the first allocation unit.

Linux on AArch64 may use 4/16/64 KiB base pages. Filesystem allocation granularity can also differ independently of the CPU architecture.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions