| View previous topic :: View next topic |
| Author |
Message |
tnt
Veteran
Joined: 27 Feb 2004
Posts: 1227
|
 Posted: Wed Jun 06, 2018 4:21 pm Post subject: to DISCARD or not to DISCARD on modern NVMe drives |
 |
|
Hello.
I have run into quite a lot of places where real-time discard/trim (used as ext4 mount option) is not recommended, even by ext4's own Theodore Ts'o:
https://forums.freebsd.org/threads/ssd-trim-maintenance.56951/#post-328912
Nevertheless, all of those articles were focusing on buggy SATA implementation of queueable TRIM command, forcing linux to revert to non-queueable version and leading to performance impact. NVMe drives were usually not mentioned.
Is there any info how successfully queueable TRIM command is implemented in modern NVMe drives like WD Black 3D, Samsung 970 EVO/PRO and similar?
Thx.
_________________
gentoo user |
|
| Back to top |
|
 |
hhfeuer
Apprentice
Joined: 28 Jul 2005
Posts: 185
|
| Posted: Wed Jun 06, 2018 6:18 pm Post subject: |
|
|
| There's no new definitive info, just the old Intel NVMe docs from 2016 where it was also advised not to turn on discard but use the periodic fstrim. Same reasons that Ts'o mentioned, especially small discards being ignored thus ineffective. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54586
Location: 56N 3W
|
| Posted: Wed Jun 06, 2018 8:39 pm Post subject: |
|
|
tnt,
The guts of the drive have not changed, only the interface to the outside world, so the guidance for SATA devices still applies.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
|
| Back to top |
|
|
tnt
Veteran
Joined: 27 Feb 2004
Posts: 1227
|
| Posted: Thu Jun 07, 2018 6:41 am Post subject: |
|
|
After so many years, I would really expect those SSD controller developers to implement some kind of list/map of blocks eligible for TRIMing and to TRIM them later/when idle. 
I guess that this is exactly what queueable TRIM should do, when implemented correctly.
_________________
gentoo user |
|
| Back to top |
|
|
P.Kosunen
Guru
Joined: 21 Nov 2005
Posts: 309
Location: Finland
|
|
| Back to top |
|
|
tnt
Veteran
Joined: 27 Feb 2004
Posts: 1227
|
| Posted: Tue Jun 12, 2018 9:41 am Post subject: |
|
|
But, if online TRIM/DISCARD is not recommended, it's quite strange that Windows is still enabling it by default. 
Windows 8/10 have scheduled TRIM via Disk Defragmenter (Optimize Drive), but real-time TRIM is still on if you do not kill it on your own.
_________________
gentoo user |
|
| Back to top |
|
|
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 205
|
| Posted: Tue Jun 12, 2018 10:47 am Post subject: |
|
|
| tnt wrote: | | But, if online TRIM/DISCARD is not recommended, it's quite strange that Windows is still enabling it by default. |
I guess Windows IO subsystem isn't as bad as Linux's. In Linux if there are a lot of discards queued up and the disk is slow at processing discards and some program calls sync() everything freeze until the queue has been processed. The same thing happens when offline trim (fstrim) is used but at least you can decide when to run it.
A patch was merged in 4.18 that will hopefully improve the situation if wtb is used.
https://github.com/torvalds/linux/commit/782f569774d7000e54ae9d680b0e4cd29b1c7ca3 |
|
| Back to top |
|
|
|
Kernel & Hardware
