On Tue, Mar 30, 2021 at 6:50 AM Hendrik Friedel <hend...@friedels.name> wrote:
> > Next > >'btrfs check --readonly' (must be done offline ie booted from usb > >stick). And if it all comes up without errors or problems, you can > >zero the statistics with 'btrfs dev stats -z'. > No error found. Neither in btrfs check, nor in scrub. > So, shall I reset the stats then? Up to you. It's probably better to zero them because it's obvious if the numbers change from 0, there's a problem. > 5.10.0-0.bpo.3-amd64 It's probably OK. I'm not sure what upstream stable version this translates into, but current stable are 5.10.27 and 5.11.11. There have been multiple btrfs bug fixes since 5.10.0 was released. I missed in your first email this line: >[Mo Mär 29 09:29:21 2021] BTRFS info (device sdc2): turning on sync discard Remove the discard mount option for this file system and see if that fixes the problem. Run it for a week or two, or until you're certain the problem is still happening (or certain it's gone). Some drives just can't handle sync discards, they become really slow and hang, just like you're reporting. It's probably adequate to just enable the fstrim.timer, part of util-linux, which runs once per week. If you have really heavy write and delete workloads, you might benefit from discard=async mount option (async instead of sync). But first you should just not do any discards at all for a while to see if that's the problem and then deliberately re-introduce just that one single change so you can monitor it for problems. -- Chris Murphy