linux-kernel - Re: [PATCH] btrfs: Don't block system suspend during fstrim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e4903dac-cfd6-4513-b7ae-7f64c80fc8b6@gmx.com>
Date: Mon, 2 Sep 2024 20:31:22 +0930
From: Qu Wenruo <quwenruo.btrfs@....com>
To: Luca Stefani <luca.stefani.ge1@...il.com>
Cc: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
 David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: Don't block system suspend during fstrim

在 2024/9/2 18:47, Qu Wenruo 写道:
[...]
> Forgot to mention that, even for error case, we should copy the
> fstrim_range structure to the ioctl parameter to indicate any progress
> we made.

Sorry to bother you again, I should have notice it earlier.

There is another possible cause of the huge delay for freezing, that's
the blkdev_issue_discard() calls inside btrfs_issue_discard() itself.

The problem here is, we can have a very large disk, e.g. 8TiB device,
mostly empty.

In that case, although we will do the split according to our super block
locations, the last super block ends at 256G, we can submit a huge
discard for the range [256G, 8T), causing a super large delay.

So the proper way here is to limit the size of each discard (e.g. limit
it to 1GiB, just as the chunk stripe size limit), and do the check after
each 1GiB discard.

So this may be a larger problem than we thought.

I would recommend to split the fix into the following parts:

- Simple small fixes
   Like always update the fstrim_range structure, no matter the return
   value.

- Proper discard size split and new freezing checks

Thanks,
Qu
>
> Thanks,
> Qu
>>
>> Just please update the commit message to explicitly mention that, we
>> have a free extent discarding phase, which can trim a lot of unallocated
>> space, and there is no limits on the trim size (unlike the block group
>> part).
>>
>> Thanks,
>> Qu
>>>
>>>     Thanks,
>>>     Qu
>>>
>>>      >>       }
>>>      >>       mutex_unlock(&fs_devices->device_list_mutex);
>>>      >
>>>
>>