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

[Luca Stefani]

On 02/09/24 13:01, Qu Wenruo wrote:
> 在 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.
Sure, that's already done. Will upload separately.
> - Proper discard size split and new freezing checks
I'll try to do the first part, and fallback to the mailing list for help 
in case of failure, thanks.
> 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);
> > > >      >