Re: [PATCH v2] fstests: generic/260: Make it handle btrfs more gracefully

[Nikolay Borisov <nborisov@suse.com>]

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@suse.com>
>>> ---
>>> 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>
>>
>