Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238858 > unrolled thread

nvme SSD and poor performance

Back to article view | Back to linux.debian.user

Contents

  nvme SSD and poor performance Pierre Willaime <pierre.willaime@univ-lorraine.fr> - 2021-08-17 12:10 +0200
    Re: nvme SSD and poor performance Dan Ritter <dsr@randomstring.org> - 2021-08-17 14:10 +0200
      Re: nvme SSD and poor performance Pierre Willaime <pierre.willaime@univ-lorraine.fr> - 2021-08-17 15:20 +0200
        Re: nvme SSD and poor performance Dan Ritter <dsr@randomstring.org> - 2021-08-17 16:10 +0200
        Re: nvme SSD and poor performance David Christensen <dpchrist@holgerdanske.com> - 2021-08-18 00:30 +0200
          Re: nvme SSD and poor performance Pierre Willaime <pierre.willaime@univ-lorraine.fr> - 2021-08-20 11:00 +0200
            Re: nvme SSD and poor performance Christian Britz <cbritz@t-online.de> - 2021-08-20 17:50 +0200
              Re: nvme SSD and poor performance Tixy <tixy@yxit.co.uk> - 2021-08-20 19:40 +0200
            Re: nvme SSD and poor performance Linux-Fan <Ma_Sys.ma@web.de> - 2021-08-20 19:20 +0200
            Re: nvme SSD and poor performance "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-08-20 19:50 +0200
              Re: nvme SSD and poor performance Pierre Willaime <pierre.willaime@univ-lorraine.fr> - 2021-08-23 10:50 +0200
                Re: nvme SSD and poor performance "Alexander V. Makartsev" <avbetev@gmail.com> - 2021-08-23 14:10 +0200
                  Re: nvme SSD and poor performance piorunz <piorunz@gmx.com> - 2021-08-23 14:20 +0200
            Re: nvme SSD and poor performance David Christensen <dpchrist@holgerdanske.com> - 2021-08-21 04:10 +0200
    Re: nvme SSD and poor performance Linux-Fan <Ma_Sys.ma@web.de> - 2021-08-17 15:40 +0200
      Re: nvme SSD and poor performance Marco Möller <talby@debianlists.mobilxpress.net> - 2021-08-17 16:10 +0200
        Re: nvme SSD and poor performance piorunz <piorunz@gmx.com> - 2021-08-20 18:30 +0200
          Re: nvme SSD and poor performance Marco Möller <talby@debianlists.mobilxpress.net> - 2021-08-20 19:20 +0200
            Re: nvme SSD and poor performance piorunz <piorunz@gmx.com> - 2021-08-20 20:10 +0200
      Re: nvme SSD and poor performance Christian Britz <cbritz@t-online.de> - 2021-08-17 17:30 +0200
        Re: nvme SSD and poor performance Linux-Fan <Ma_Sys.ma@web.de> - 2021-08-17 17:40 +0200
    Re: nvme SSD and poor performance Stefan Monnier <monnier@iro.umontreal.ca> - 2021-08-17 17:00 +0200
    Re: nvme SSD and poor performance Jochen Spieker <ml@well-adjusted.de> - 2021-08-18 22:00 +0200
      Re: nvme SSD and poor performance Anssi Saari <as@sci.fi> - 2021-08-19 08:10 +0200
        Re: nvme SSD and poor performance Sven Hartge <sven@svenhartge.de> - 2021-08-21 15:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#238888

[Multipart message — attachments visible in raw view] — view raw

Christian Britz writes:

> On 17.08.21 at 15:30 Linux-Fan wrote:
>> Pierre Willaime writes:
>>
>>> P-S: If triming it is needed for ssd, why debian do not trim by default?
>>
>> Detecting reliably if the current system has SSDs that would benefit from  
>> trimming AND that the user has not taken their own measures is difficult. I  
>> guess this might be the reason for there not being an automatism, but you  
>> can enable the systemd timer suggested above with a single command.
>
> I am pretty sure that I have never played with fstrim.timer and this is the  
> output of "systemctl status fstrim.timer" on my bullseye system:
>
> ● fstrim.timer - Discard unused blocks once a week
>      Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor  
> preset: enabled)
>      Active: active (waiting) since Tue 2021-08-17 14:10:17 CEST; 3h 5min ago
>     Trigger: Mon 2021-08-23 01:01:39 CEST; 5 days left
>    Triggers: ● fstrim.service
>        Docs: man:fstrim
>
> So it seems this weekly schedule is enabled by default on bullseye.

Nice, thanks for sharing :)

> BTW, if my system is not online at that time, will it be triggered on next  
> boot?

Yes, I would think so.

A systemd timer can be configured to run if its schedule is missed by  
`[Timer] Persistent=true` which on my machine is configured for  
`fstrim.timer` (check `systemctl cat fstrim.timer`).

See also: https://jeetblogs.org/post/scheduling-jobs-cron-anacron-systemd/

Of course, it is also possible to find out experimentally. Check
`systemctl list-timers` to find out about all registered timers and when  
they ran last.

HTH
Linux-Fan

öö

[toc] | [prev] | [next] | [standalone]

#238883

> P-S: If triming it is needed for ssd, why debian do not trim by default?

AFAIK trimming is not needed.  It can be beneficial in some cases, but
as a general rule, the SSDs should be able to provide great performance
without it.


        Stefan

[toc] | [prev] | [next] | [standalone]

#238978

[Multipart message — attachments visible in raw view] — view raw

Pierre Willaime:
> 
> Using fstrim seems to restore speed. There are always many GiB which are
> reduced :
> 
> 	#  fstrim -v /
> 	/ : 236,7 GiB (254122389504 octets) réduits

This is probably the total amount of unused space on that SSD. The first
fstrim run after a reboot always trims all free space, as far as I
understand. After that, only space that was freed since the last fstrim
run will be trimmed.

> then, directly after :
> 
> 	#  fstrim -v /
> 	/ : 0 B (0 octets) réduits

See above, this is expected.

> but few minutes later, there are already 1.2 Gib to trim again :
> 
> 	#  fstrim -v /
> 	/ : 1,2 GiB (1235369984 octets) réduits

It is odd that something wrote and deleted 1.2 GB in "a few minutes". I
would run iotop to see what process is responsible.

> /Is it a good idea to trim, if yes how (and how often)?/

See the other answers. Usually once per week is enough, but that assumes
that the free space is not overwritten and freed again several times
each day.

On the other hand, personally I have never felt a difference in
performance before and after an fstrim run.

> Some people use fstrim as a cron job, some other add "discard" option to the
> /etc/fstab / line. I do not know what is the best if any. I also read
> triming frequently could reduce the ssd life.

Stay away from the "discard" option and do not worry about SSD life.
Even with heavy usage you should not exceed the expected lifetime
writes. Do worry about data loss in general and create a viable backup
strategy, independent of the storage medium (or service) that you are
using.

> I also noticed many I/O access from jbd2 and kworker such as :
> 
> 	# iotop -bktoqqq -d .5
> 	11:11:16     364 be/3 root        0.00 K/s    7.69 K/s  0.00 % 23.64 %
> [jbd2/nvme0n1p2-]
> 	11:11:16       8 be/4 root        0.00 K/s    0.00 K/s  0.00 % 25.52 %
> [kworker/u32:0-flush-259:0]

jbd2 is the journalling service of the filesystem and makes sure that
your filesystem does not become corrupt in case of power failures. 

kworkers are general purpose kernel threads doing kernel stuff, for
example disk I/O. Seeing these is not a problem in itself.

> 

-- 
I spend money without thinking on products and clothes that I believe
will enhance my social standing.
[Agree]   [Disagree]
                 <http://archive.slowlydownward.com/NODATA/data_enter2.html>

[toc] | [prev] | [next] | [standalone]

#239006

Jochen Spieker <ml@well-adjusted.de> writes:

> Stay away from the "discard" option and do not worry about SSD life.

What's the issue with the discard option? AFAIK, there may have been
issues with it in the decade before last but again AFAIK, today some
distros enable discard and some run fstrim on timer, both work.

But please share.

[toc] | [prev] | [next] | [standalone]

#239115

Anssi Saari <as@sci.fi> wrote:
> Jochen Spieker <ml@well-adjusted.de> writes:

>> Stay away from the "discard" option and do not worry about SSD life.

> What's the issue with the discard option? AFAIK, there may have been
> issues with it in the decade before last but again AFAIK, today some
> distros enable discard and some run fstrim on timer, both work.

> But please share.

This may be part cargo culting and part real problem.

In the past it was shown that many SSD needed to flush their whole queue
whenever a TRIM command was received and the Kernel was really zealos of
sending those for every block freed. 

This basically neutered many SSD and even caused corruption issues on
some especially shoddy ones.

Some firmwares got fixed and newer drives don't suffer from the same
problems, but even now end then you can find some devices on the lower
end of the consumer spectrum behaving poorly when bombarded with TRIM
commands.

So in the end the consensous was to just play it safe and batch-TRIM
once a week or day, because TRIMming on demand hasn't been shown to be a
big win.

It is far easier to fall back on that option than trying to
good/bad-list specific drive or firmware versions and select the
appropriate TRIM method.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web