On Mon, Nov 20, 2017 at 11:10 PM, Qu Wenruo <[email protected]> wrote:
>
>
> On 2017年11月21日 13:58, Chris Murphy wrote:
>> On Mon, Nov 20, 2017 at 9:58 PM, Qu Wenruo <[email protected]> wrote:
>>>
>>>
>>> On 2017年11月21日 12:49, Chris Murphy wrote:
>>>> On Mon, Nov 20, 2017 at 9:43 PM, Qu Wenruo <[email protected]> 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.
I still see this problem in 4.16.0-0.rc7.git1.1.fc29.x86_64. Are there
any patches to test?
[chris@f27h mnt]$ sudo btrfs fi us /
Overall:
Device size: 70.00GiB
Device allocated: 60.06GiB
Device unallocated: 9.94GiB
Device missing: 0.00B
Used: 36.89GiB
Free (estimated): 29.75GiB (min: 24.78GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 107.77MiB (used: 12.38MiB)
Data,single: Size:55.00GiB, Used:35.19GiB
/dev/nvme0n1p9 55.00GiB
Metadata,single: Size:5.00GiB, Used:1.70GiB
/dev/nvme0n1p9 5.00GiB
System,DUP: Size:32.00MiB, Used:16.00KiB
/dev/nvme0n1p9 64.00MiB
Unallocated:
/dev/nvme0n1p9 9.94GiB
[chris@f27h mnt]$ sudo fstrim -v /
[sudo] password for chris:
/: 10 GiB (10669260800 bytes) trimmed
--
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
