在 2024/5/8 18:21, Zorro Lang 写道: [...]
Hey Zorro, Any remaining concerns for adding this test? I could run it across more file systems(bcachefs could be interesting) and share the results if needed be.Hi, I remembered you metioned btrfs fails on this test, and I can reproduce it on btrfs [1] with general disk. Have you figured out the reason? I don't want to give btrfs a test failure suddently without a proper explanation :) If it's a case issue, better to fix it for btrfs. Thanks, Zorro # ./check generic/744 FSTYP -- btrfs PLATFORM -- Linux/x86_64 hp-dl380pg8-01 6.9.0-0.rc5.20240425gite88c4cfcb7b8.47.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 25 14:21:52 UTC 2024 MKFS_OPTIONS -- /dev/sda4 MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/sda4 /mnt/scratch generic/744 115s ... [failed, exit status 1]- output mismatch (see /root/git/xfstests/results//generic/744.out.bad) --- tests/generic/744.out 2024-05-08 16:11:14.476635417 +0800 +++ /root/git/xfstests/results//generic/744.out.bad 2024-05-08 16:46:03.617194377 +0800 @@ -2,5 +2,4 @@ Starting fillup using direct IO Starting mixed write/delete test using direct IO Starting mixed write/delete test using buffered IO -Syncing -Done, all good +dd: error writing '/mnt/scratch/data_82': No space left on device
[POSSIBLE CAUSE] Not an expert on zoned support, but even with the 95% fill rate setup, the test case still go fully filled btrfs data, thus no more data can be written. My guess is, the available space has taken some metadata space into consideration, thus at the end of the final available bytes of data space, the `stat -f -c '%a'` still reports some value larger than 5%. But as long as the data space is full filled up, btrfs notice that there is no way to allocate more data, thus reports its available bytes as 0. This means, the available space report is always beyond 5%, then suddenly dropped to 0, causing the test script to fail. Unfortunately I do not have any good idea that can easily solve the problem. Due to the nature of dynamic block groups allocation, the available/free space reporting is always not that reliable. [WORKAROUND?] I'm just wondering if it's possible that, can we fill up the fs to 100% (hitting ENOSPC), then just remove 5% of all the files to emulate 95% filled up fs? By this, it can be a more accurate way to emulate 95% used data space, without relying on the fs specific available space reporting. Thanks, Qu
... (Run 'diff -u /root/git/xfstests/tests/generic/744.out /root/git/xfstests/results//generic/744.out.bad' to see the entire diff) Ran: generic/744 Failures: generic/744 Failed 1 of 1 testsThanks, Hans
