weekly fstrim (still) necessary?

weekly fstrim (still) necessary?

[Ulli Horlacher]

On SLES a weekly fstrim is done via a btrfsmaintenance script, which is
missing on Ubuntu.

For ext4 filesystem an explicite fstrim call is no longer neccessary, what
about btrfs?
Shall I call fstrim via /etc/cron.weekly ?



-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<20200621054240.GA25387@tik.uni-stuttgart.de>

Re: weekly fstrim (still) necessary?

[Andrei Borzenkov]

21.06.2020 08:42, Ulli Horlacher пишет:
> On SLES a weekly fstrim is done via a btrfsmaintenance script, which is
> missing on Ubuntu.
> 
> For ext4 filesystem an explicite fstrim call is no longer neccessary,

Why?

> what
> about btrfs?
> Shall I call fstrim via /etc/cron.weekly ?
> 

It is really up to you. Is it question about distribution defaults, or
what exactly are you asking?

Re: weekly fstrim (still) necessary?

[Lukas Tribus]

Hello,

On Sun, 21 Jun 2020 at 07:42, Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
> On SLES a weekly fstrim is done via a btrfsmaintenance script, which is
> missing on Ubuntu.
>
> For ext4 filesystem an explicite fstrim call is no longer neccessary, what
> about btrfs?
> Shall I call fstrim via /etc/cron.weekly ?

Unless you mount with the discard option [1], I'd say yes, the manpage
suggests so.


--lukas

[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#MOUNT_OPTIONS

Re: weekly fstrim (still) necessary?

[Adam Borowski]

On Sun, Jun 21, 2020 at 07:42:40AM +0200, Ulli Horlacher wrote:
> On SLES a weekly fstrim is done via a btrfsmaintenance script, which is
> missing on Ubuntu.
> 
> For ext4 filesystem an explicite fstrim call is no longer neccessary, what
> about btrfs?
> Shall I call fstrim via /etc/cron.weekly ?

Both ext4 and btrfs may or may not auto-discard in the write path, depending
on mount option.  A lot of disks handle such frequent small discards poorly
-- usually with a greatly decreased performance, although data loss in not
unknown.

If you test your disk and know that it is happy with tons of small discards,
then the discard mount option is good for you.  Otherwise, you want to do
large discards once in a while -- be it a day or a week.

Not discarding at all is a bad idea on most disks.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀                                       -- <willmore> on #linux-sunxi
⠈⠳⣄⠀⠀⠀⠀

Re: weekly fstrim (still) necessary?

[Chris Murphy]

On Sat, Jun 20, 2020 at 11:50 PM Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
> On SLES a weekly fstrim is done via a btrfsmaintenance script, which is
> missing on Ubuntu.
>
> For ext4 filesystem an explicite fstrim call is no longer neccessary, what
> about btrfs?
> Shall I call fstrim via /etc/cron.weekly ?

util-linux provides fstrim.service and fstrim.timer for a while now.
fstrim.timer runs on Monday at 00:00 local time. The upstream default
is disabled, some distributions enable it by default. You can use this
until your kernel supports discard=async mount option for btrfs.


-- 
Chris Murphy

Re: weekly fstrim (still) necessary?

[Ulli Horlacher]

On Sun 2020-06-21 (13:39), Chris Murphy wrote:

> > Shall I call fstrim via /etc/cron.weekly ?
> 
> util-linux provides fstrim.service and fstrim.timer for a while now.
> fstrim.timer runs on Monday at 00:00 local time. The upstream default
> is disabled, some distributions enable it by default.

On Ubuntu 18.04 and RHEL 7.8 "systemctl is-enabled fstrim" returns
"static"


This means: an extra fstrim (via btrfsmaintenance script, etc) is
unnecessary? 


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<CAJCQCtSbCid6OzvjK9fxXZosS_PAk2Lr7=VTpNijuuZXmRVVEg@mail.gmail.com>

Re: weekly fstrim (still) necessary?

[Chris Murphy]

On Sun, Jun 21, 2020 at 5:52 PM Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
> On Sun 2020-06-21 (13:39), Chris Murphy wrote:
>
> > > Shall I call fstrim via /etc/cron.weekly ?
> >
> > util-linux provides fstrim.service and fstrim.timer for a while now.
> > fstrim.timer runs on Monday at 00:00 local time. The upstream default
> > is disabled, some distributions enable it by default.
>
> On Ubuntu 18.04 and RHEL 7.8 "systemctl is-enabled fstrim" returns
> "static"

You need to check fstrim.timer, which in turn triggers fstrim.service.


-- 
Chris Murphy

Re: weekly fstrim (still) necessary?

[Ulli Horlacher]

On Sun 2020-06-21 (17:57), Chris Murphy wrote:

> > > util-linux provides fstrim.service and fstrim.timer for a while now.
> > > fstrim.timer runs on Monday at 00:00 local time. The upstream default
> > > is disabled, some distributions enable it by default.
> >
> > On Ubuntu 18.04 and RHEL 7.8 "systemctl is-enabled fstrim" returns
> > "static"
> 
> You need to check fstrim.timer, which in turn triggers fstrim.service.

root@fex:~# cat /lib/systemd/system/fstrim.timer
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target


root@fex:~# cat /lib/systemd/system/fstrim.service 
[Unit]
Description=Discard unused blocks
ConditionVirtualization=!container

[Service]
Type=oneshot
ExecStart=/sbin/fstrim -av



-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<CAJCQCtQmrc5m=H6d6xZiGvuzRrxBhf=wgf8bAMXZ_4p8F3AJFw@mail.gmail.com>

Re: weekly fstrim (still) necessary?

[Chris Murphy]

On Sun, Jun 21, 2020 at 6:06 PM Ulli Horlacher
<framstag@rus.uni-stuttgart.de> wrote:
>
> On Sun 2020-06-21 (17:57), Chris Murphy wrote:
>
> > > > util-linux provides fstrim.service and fstrim.timer for a while now.
> > > > fstrim.timer runs on Monday at 00:00 local time. The upstream default
> > > > is disabled, some distributions enable it by default.
> > >
> > > On Ubuntu 18.04 and RHEL 7.8 "systemctl is-enabled fstrim" returns
> > > "static"
> >
> > You need to check fstrim.timer, which in turn triggers fstrim.service.
>
> root@fex:~# cat /lib/systemd/system/fstrim.timer
> [Unit]
> Description=Discard unused blocks once a week
> Documentation=man:fstrim
> ConditionVirtualization=!container
>
> [Timer]
> OnCalendar=weekly
> AccuracySec=1h
> Persistent=true
>
> [Install]
> WantedBy=timers.target
>
>
> root@fex:~# cat /lib/systemd/system/fstrim.service
> [Unit]
> Description=Discard unused blocks
> ConditionVirtualization=!container
>
> [Service]
> Type=oneshot
> ExecStart=/sbin/fstrim -av
>

I'm familiar with the contents of the files. Do you have a question?


-- 
Chris Murphy

Re: weekly fstrim (still) necessary?

[Ulli Horlacher]

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?


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<CAJCQCtQ8GFAdg2HJY_HqDgW8WAp5L1GoLbKqUN2mZ7s_kS-8XA@mail.gmail.com>

Re: weekly fstrim (still) necessary?

[David Sterba]

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.

Re: weekly fstrim (still) necessary?

[Chris Mason]

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

Fwd: weekly fstrim (still) necessary?

[Tim Cuthbertson]

---------- Forwarded message ---------
From: Chris Mason <clm@fb.com>
Date: Mon, Jun 22, 2020 at 10:57 AM
Subject: Re: weekly fstrim (still) necessary?
To: David Sterba <dsterba@suse.cz>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>


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

Re: weekly fstrim (still) necessary?

[Chris Mason]

On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote:

> ---------- Forwarded message ---------
> From: Chris Mason <clm@fb.com>
> Date: Mon, Jun 22, 2020 at 10:57 AM
> Subject: Re: weekly fstrim (still) necessary?
> To: David Sterba <dsterba@suse.cz>
> Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
>
>
> 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?

-chris

Re: weekly fstrim (still) necessary?

[Chris Murphy]

On Fri, Jun 26, 2020 at 9:40 AM Chris Mason <clm@fb.com> wrote:
>
> On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote:
>
> > ---------- Forwarded message ---------
> > From: Chris Mason <clm@fb.com>
> > Date: Mon, Jun 22, 2020 at 10:57 AM
> > Subject: Re: weekly fstrim (still) necessary?
> > To: David Sterba <dsterba@suse.cz>
> > Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
> >
> >
> > 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

Re: weekly fstrim (still) necessary?

[Chris Mason]

On 26 Jun 2020, at 12:40, Chris Murphy wrote:

> On Fri, Jun 26, 2020 at 9:40 AM Chris Mason <clm@fb.com> wrote:
>>
>> On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote:
>>
>>> ---------- Forwarded message ---------
>>> From: Chris Mason <clm@fb.com>
>>> Date: Mon, Jun 22, 2020 at 10:57 AM
>>> Subject: Re: weekly fstrim (still) necessary?
>>> To: David Sterba <dsterba@suse.cz>
>>> Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
>>>
>>>
>>> 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.

It should do the right thing, any conflict there would be a kernel bug.  
But since we don’t do fstrim here, it seems like the mostly likely 
spot a bug would hide.

-chris

Re: weekly fstrim (still) necessary?

[Tim Cuthbertson]

Oh, no. No fstrims were run during the short length of time that I was
trying discard=async. I run my fstrims, manually.

Tim

On Fri, Jun 26, 2020 at 11:41 AM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Fri, Jun 26, 2020 at 9:40 AM Chris Mason <clm@fb.com> wrote:
> >
> > On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote:
> >
> > > ---------- Forwarded message ---------
> > > From: Chris Mason <clm@fb.com>
> > > Date: Mon, Jun 22, 2020 at 10:57 AM
> > > Subject: Re: weekly fstrim (still) necessary?
> > > To: David Sterba <dsterba@suse.cz>
> > > Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
> > >
> > >
> > > 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

Fwd: weekly fstrim (still) necessary?

[Tim Cuthbertson]

---------- Forwarded message ---------
From: Tim Cuthbertson <ratcheer@gmail.com>
Date: Fri, Jun 26, 2020 at 2:30 PM
Subject: Re: weekly fstrim (still) necessary?
To: Chris Mason <clm@fb.com>


Well, I am going back to using a weekly, manual fstrim. I have been
doing that for many months with no issues.

I cannot be certain that discard=async caused the problem. However, I
had implemented that for the first time less than two days before I
discovered the problem. My system was still booting and seeming to run
fine, but then Firefox refused to start. I was looking for the problem
and I found csum errors in the systemd journal. Then, I ran btrfs
scrub, and found that there were 12,936 csum errors.

The systemd journals should still be available, if you'd like me to post them.

Tim

On Fri, Jun 26, 2020 at 10:40 AM Chris Mason <clm@fb.com> wrote:
>
> On 26 Jun 2020, at 8:08, Tim Cuthbertson wrote:
>
> > ---------- Forwarded message ---------
> > From: Chris Mason <clm@fb.com>
> > Date: Mon, Jun 22, 2020 at 10:57 AM
> > Subject: Re: weekly fstrim (still) necessary?
> > To: David Sterba <dsterba@suse.cz>
> > Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
> >
> >
> > 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?
>
> -chris

Re: weekly fstrim (still) necessary?

[Tim Cuthbertson]

I was running kernel 5.7.5 on a fully updated Arch Linux desktop system.

On Fri, Jun 26, 2020 at 2:33 PM Chris Mason <clm@fb.com> wrote:
>
> On 26 Jun 2020, at 15:30, Tim Cuthbertson wrote:
>
> > Well, I am going back to using a weekly, manual fstrim. I have been
> > doing that for many months with no issues.
> >
> > I cannot be certain that discard=async caused the problem. However, I
> > had implemented that for the first time less than two days before I
> > discovered the problem. My system was still booting and seeming to run
> > fine, but then Firefox refused to start. I was looking for the problem
> > and I found csum errors in the systemd journal. Then, I ran btrfs
> > scrub, and found that there were 12,936 csum errors.
> >
> > The systemd journals should still be available, if you'd like me to
> > post them.
>
> I’ll try reproducing things, which kernel were you running?
>
> -chris

Re: weekly fstrim (still) necessary?

[Remi Gauvin]

[-- Attachment #1.1: Type: text/plain, Size: 560 bytes --]

On 2020-06-26 11:40 a.m., Chris Mason wrote:

> 
> 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?
> 
> -chris
> 


I'm probably just confusing the terminology... But could this be related
to the queued trim problems with Samsung for which they should be
blakclisted?


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: weekly fstrim (still) necessary?

[Roman Mamedov]

On Fri, 26 Jun 2020 16:18:03 -0400
Remi Gauvin <remi@georgianit.com> wrote:

> I'm probably just confusing the terminology... But could this be related
> to the queued trim problems with Samsung for which they should be
> blakclisted?
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81

A Samsung 860 SSD that I have is the worst (compared to a dozen non-Samsung
ones) when it comes to TRIM, NCQ, combination thereof, and compatibility with
various SATA controllers.

However it should be noted that while the commit referenced is not in the
mainline kernel anymore, a narrower blacklist applying to 840 and 850 models
currently is [1]. And as the report is about the 850 Pro, queued TRIM should
not have been the cause, as is already blacklisted in kernel for all "Samsung
SSD 850". Can check in 'dmesg' for a note about it shortly after the SSD
detection to confirm.

[1]
https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c#L3952

-- 
With respect,
Roman

Re: weekly fstrim (still) necessary?

[Jan Killius]

discard=async triggers continuous disc activity for me without any
calls to the filesystem.
Is this intentional?

On Mon, Jun 22, 2020 at 5:57 PM Chris Mason <clm@fb.com> wrote:
>
> 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