Re: bug? fstrim only trims unallocated space, not unused in bg's

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2416 bytes --]



On 2017年11月21日 13:58, Chris Murphy wrote:
> On Mon, Nov 20, 2017 at 9:58 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>> On 2017年11月21日 12:49, Chris Murphy wrote:
>>> On Mon, Nov 20, 2017 at 9:43 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>
>>>>
>>>>>
>>>>> Apply in addition to previous patch? Or apply to clean v4.14?
>>>>
>>>> On previous patch.
>>>
>>> Refuses to apply with or without previous patch.
>>>
>>> $ git apply -v ~/qufstrim3.patch
>>> Checking patch fs/btrfs/extent-tree.c...
>>> error: while searching for:
>>>        int dev_ret = 0;
>>>        int ret = 0;
>>>
>>>        /*
>>>         * try to trim all FS space, our block group may start from non-zero.
>>>         */
>>>
>>> error: patch failed: fs/btrfs/extent-tree.c:10972
>>> error: fs/btrfs/extent-tree.c: patch does not apply
>>>
>>
>> Please try this branch.
>>
>> It's just previous patch and diff merged together and applied on v4.14
>> tag from torvalds.
>>
>> https://github.com/adam900710/linux/tree/tmp
> 
> # fstrim -v /
> /: 38 GiB (40767586304 bytes) trimmed
> # dmesg
> 
> ..snip...
> [   46.408792] BTRFS info (device nvme0n1p8): trimming btrfs, start=0
> len=75161927680 minlen=512
> [   46.408800] BTRFS info (device nvme0n1p8): bg start=140882477056
> len=1073741824
> [   46.433867] BTRFS info (device nvme0n1p8): trimming done

Great (for the output, not for the trimming failure).

And the problem is very obvious now.
140882477056 << First chunk start
75161927680  << length of fstrim_range passed in

Obviously, fstrim_range passed in is using the filesystem size it
assumes to be.

While we stupidly use the range in fstrim_range without considering the
fact that, we're dealing with *btrfs logical address space*.
Where our chunk can start from any bytenr (well, at least aligned with
sectorsize).
When I read the code I also think the range check has nothing wrong at all.

So the truth here is, we should not ever try to check the range from
fstrim_range.

And the problem means that, a normal btrfs with some usage and after
several full balance, fstrim will only trim the unallocated space for btrfs.

Now the fix should not be a hard to craft.

Great thanks for all your help to locate the problem.

Thanks,
Qu
> 
> Attaching 'btrfs-debug -b /' to get an idea about the block groups present.
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]