---------- Forwarded message --------- From: Chris Mason <clm@xxxxxx> Date: Mon, Jun 22, 2020 at 10:57 AM Subject: Re: weekly fstrim (still) necessary? To: David Sterba <dsterba@xxxxxxx> Cc: Btrfs BTRFS <linux-btrfs@xxxxxxxxxxxxxxx> On 22 Jun 2020, at 10:23, David Sterba wrote: > On Mon, Jun 22, 2020 at 04:02:34PM +0200, Ulli Horlacher wrote: >> On Sun 2020-06-21 (18:57), Chris Murphy wrote: >> >>>>> You need to check fstrim.timer, which in turn triggers >>>>> fstrim.service. >>>> >>>> root@fex:~# cat /lib/systemd/system/fstrim.timer >>>> >>>> root@fex:~# cat /lib/systemd/system/fstrim.service >> >>> I'm familiar with the contents of the files. Do you have a question? >> >> >> You have deleted my question, it have asked: >> >> This means: an extra fstrim (via btrfsmaintenance script, etc) is >> unnecessary? > > You need only one service, either from the fstrim or from > btrfsmaintenance. Dennis’s async discard features are working much better here than either periodic trims or the traditional mount -o discard. I’d suggest moving to mount -o discard=async instead. -chris Apparently, discard=async is still unsafe on Samsung SSDs, at least older models. I enabled it on my 850 Pro, and within two days I was getting uncorrectable errors (for csums). Scrub showed 12,936 uncorrectable errors. While I was trying to recover, a long SMART analysis showed the actual drive to have no errors. Then, the first recovery attempt failed. I had deleted and recreated the partition. When I was copying the backup snapshots back to the SSD, uncorrectable errors showed up, again (4,119 of them after copying one snapshot). I then overwrote the partition with all zeros, and when I copied the snapshots back to it, there were no errors. After recovering my filesystem, scrub still showed no errors. So, alls well that ends well, I guess. Tim
