On 2019/6/5 下午7:16, Nikolay Borisov wrote:
>
>
> On 3.06.19 г. 9:40 ч., Qu Wenruo wrote:
>> If a filesystem doesn't map its logical address space (normally the
>> bytenr/blocknr returned by fiemap) directly to its devices(s), the
>> following assumptions used in the test case is no longer true:
>> - trim range start beyond the end of fs should fail
>> - trim range start beyond the end of fs with len set should fail
>>
>> Under the following example, even with just one device, btrfs can still
>> trim the fs correctly while breaking above assumption:
>>
>> 0 1G 1.25G
>> |---------------|///////////////|-----------------| <- btrfs logical
>> | address space
>> ------------ mapped as SINGLE
>> |
>> 0 V 256M
>> |///////////////| <- device address space
>>
>> Thus trim range start=1G len=256M will cause btrfs to trim the 256M
>> block group, thus return correct result.
>>
>> Furthermore, there is no cleared defined behavior for whether a fs should
>> trim the unmapped space. (only for indirectly mapped fs)
>>
>> Btrfs currently will always trim the unmapped space, but the behavior
>> can change as large trim can be very expensive.
>>
>> Despite the change to skip certain tests for btrfs, still run the
>> following tests for btrfs:
>> - trim start=U64_MAX with lenght set
>> This will expose a bug that btrfs doesn't check overflow of the range.
>> This bug will be fixed soon.
>>
>> - trim beyond the end of the fs
>> This will expose a bug where btrfs could send trim command beyond the
>> end of its device.
>> This bug is a regression, can be fixed by reverting c2d1b3aae336 ("btrfs:
>> Honour FITRIM range constraints during free space trim")
>>
>> With proper fixes for btrfs, this test case should pass on btrfs, ext4,
>> xfs.
>>
>> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
>> ---
>> changelog:
>> v2:
>> - Return 0/1 instead of echo "1"/"0" for _is_fs_directly_mapped
>> Although it may be a little confusing, but make
>> "if _is_fs_directly_mapped; then" much cleaner.
>> - Comment change.
>> ---
>
> Nope, the output is rather unhelpful. Current misc-next of btrfs fails
> and the output is:
This is not the output. This is seqres.full.
For output, using 5.2-rc2, btrfs would fail like:
[+] Optional trim range test (fs dependent)
[+] Default length (should succeed)
[+] Default length with start set (should succeed)
[+] Length beyond the end of fs (should succeed)
[+] Length beyond the end of fs with start set (should succeed)
Unexpected error happened during trim
Test done
Which is already good enough to show what's wrong.
>
> [+] Start = 2^64-1 and len is set (should fail)
>
> [+] Trim an empty fs
>
> 13554941952 trimed
>
> [+] Try to trim beyond the end of the fs
>
> [+] Try to trim the fs with large enough len
>
> 15727198208 trimed
For this full, try it on 5.2-rc2, then you would understand why it's here:
[+] Start = 2^64-1 and len is set (should fail) << It doesn't fail
[+] Trim an empty fs
0 trimed << It trimmed 0 bytes, isn't it already a problem?
[+] Try to trim beyond the end of the fs
fstrim: /mnt/scratch: FITRIM ioctl failed: Input/output error << Beyond
device end bug
[+] Try to trim the fs with large enough len
5367267328 trimed << The only good result here.
>
> generic/260 [failed, exit status 1]
>
>
> There is no 260.out file which is supposed to contain some of the error
> strings which in turn makes the test tedious to debug...
I'm afraid you're checking the wrong file.
Thanks,
Qu
>
>
> <snip>
>
