Re: fstrim is takes a long time on Btrfs and NVMe

[Josef Bacik <josef@toxicpanda.com>]

On 12/22/19 12:49 PM, Nikolay Borisov wrote:
> 
> 
> On 22.12.19 г. 19:43 ч., Josef Bacik wrote:
>> On 12/21/19 1:24 AM, Chris Murphy wrote:
>>> Hi,
>>>
>>> Recent kernels, I think since 5.1 or 5.2, but tested today on 5.3.18,
>>> 5.4.5, 5.5.0rc2, takes quite a long time for `fstrim /` to complete,
>>> just over 1 minute.
>>>
>>> Filesystem      Size  Used Avail Use% Mounted on
>>> /dev/nvme0n1p7  178G   16G  161G   9% /
>>>
>>> fstrim stops on this for pretty much the entire time:
>>> ioctl(3, FITRIM, {start=0, len=0xffffffffffffffff, minlen=0}) = 0
>>>
>>> top shows the fstrim process itself isn't consuming much CPU, about
>>> 2-3%. Top five items in per top, not much more revealing.
>>>
>>> Samples: 220K of event 'cycles', 4000 Hz, Event count (approx.):
>>> 3463316966 lost: 0/0 drop: 0/0
>>> Overhead  Shared Object                    Symbol
>>>      1.62%  [kernel]                         [k] find_next_zero_bit
>>>      1.59%  perf                             [.] 0x00000000002ae063
>>>      1.52%  [kernel]                         [k] psi_task_change
>>>      1.41%  [kernel]                         [k] update_blocked_averages
>>>      1.33%  [unknown]                        [.] 0000000000000000
>>>
>>> On a different system, with older Samsung 840 SATA SSD, and a fresh
>>> Btrfs, I can't reproduce. It takes less than 1s. Not sure how to get
>>> more information.
>>>
>>>
>>
>> You want to try Dennis's async discard stuff?  That should fix these
>> problems for you, the patches are in Dave's tree.  Thanks,
> 
> But aren't those only for inline discards e.g. when you have explicitly
> mounted with discard. The use case here is using FITRIM ioctl, does
> Dennis' stuff fix this?
> 

I definitely misread the email, I thought he was talking about the commits being 
slow.  The async discard stuff won't help with fitrim taking forever, there's 
only so much we can do in the face of shitty ssd's.  Thanks,

Josef