On 5.06.19 г. 14:53 ч., Qu Wenruo wrote:
>
>
> 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.
I don't have an .out file produced!
>
> Thanks,
> Qu
>
>>
>>
>> <snip>
>>
>
