On Fri, Jun 26, 2020 at 9:40 AM Chris Mason <clm@xxxxxx> wrote: > > On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote: > > > ---------- 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. > > We’re using this on a pretty wide variety of hardware, so I’m > surprised to hear this. Are you able to reproduce the problem? Is a > periodic fstrim still happening? > I'm curious if there's a possibility of confusion/conflict between scheduled fstrim combined with either discard or discard=async. As in, if it's a big enough concern, maybe the scheduled fstrim needs to get smarter and parse mount options, and automatically deconflict. -- Chris Murphy
