Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[SOLVED] New SSD

Here you can discuss every aspect of Debian. Note: not for support requests!
Post Reply
Message
Author
User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

[SOLVED] New SSD

#1 Post by ticojohn »

Well, I finally broke down and bought an SSD for my aging 32 bit machine. Got a Samsung 850 EVO 250 GB drive. I decided that since my MB only has Sata II, buying the faster 850 PRO wasn't going to buy me much. So, I installed Jessie and have spent much of the day installing software, transferring passwords and bookmarks, etc etc etc. I had thought about using Grsync to restore my /home backup (from Wheezy) to the new Jessie install and then thought, MAYBE BETTER NOT. Might be some gotcha there. Still have the Wheezy install as a backup.

The SSD is perceptibly faster. Boot time is probably about 50%, or less, then the HDD. Of course the SSD and HDD are not the same size but if I am correct, the smaller the SSD the less fast they are (generally speaking). Anyhow, programs launch a lot faster and I am happy, so far, with the install. Don't really care for the Gnome Classic implementation (really don't like the new Gnome at all) so I am running LXDE.

All in all a good day. Stuff yet to do: Install NUT and set up the UPS, install the printer drivers (older printer), and boogie !
Last edited by ticojohn on 2016-11-28 16:45, edited 1 time in total.
I am not irrational, I'm just quantum probabilistic.

emariz
Posts: 2901
Joined: 2008-10-17 07:59

Re: New SSD

#2 Post by emariz »

Two tips:
1. Remember to mount file systems using the noatime option,
2 and to trim your SSD every week or so (man fstrim.)

I would also tell Firefox not to save the cache in the disk, and set the tendency to move processes to swap (swappiness) as low as possible. The idea is to reduce the disk access.

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: New SSD

#3 Post by Head_on_a_Stick »

I also have a Samsung EVO 850, it is an excellent device.

Personally, I am not at all worried about limiting writes to the drive because it will probably last longer than a spinning rust equivalent, see http://techreport.com/review/27909/the- ... e-all-dead for an endurance test that involves the 850's predecessor.

Also, noatime breaks mutt :shock:

A systemd .timer that will automatically run `fstrim -a` every week can be enabled in Debian with these commands:

Code: Select all

# apt install util-linux
# cp /usr/share/doc/util-linux/examples/fstrim.{service,timer} /etc/systemd/system
# systemctl enable fstrim.timer
Check the status of the .timer with:

Code: Select all

systemctl list-timers
Stop the .timer from running automatically with:

Code: Select all

# systemctl disable fstrim.timer
Read `man systemctl` & `man systemd.timer` for more on this.

EDIT: more opinions can be found in this thread:

http://forums.debian.net/viewtopic.php?f=17&t=130615
deadbang

User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

Re: New SSD

#4 Post by ticojohn »

Thanks for the feedback. I did set up fstab to use noatime. And I do not do any automatic trimming, just do fstrim -a once a week. Once I get everything working I may look into disk cache issues.

And I don't use MUTT so no issues there. Been using noatime on my Intel NUC, running Stretch, and have not experienced any problems.
I am not irrational, I'm just quantum probabilistic.

User avatar
sjukfan
Posts: 386
Joined: 2010-03-01 19:39

Re: New SSD

#5 Post by sjukfan »

I love to make things complicated so I put /tmp in ram and /home on a plain old harddrive to prevent overly active writing on my ssd. Even if I know that modern ssd have a life time of over 10 years. And by then I hope I have a faster computer with a new and shiny system for storing data. Who knows, maybe some biological kind of disks that save the data in proteins? :D
Bullseye amd64, AMD Ryzen 5 3600
Buster amd64, Intel Xeon E3-1240 v3
Sid ppc, PowerPC 7447a
Sid ppc64, PowerPC 970FX

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: New SSD

#6 Post by phenest »

sjukfan wrote:Who knows, maybe some biological kind of disks that save the data in proteins? :D
You watch too much Star Trek.

What is the need for trim once a week? I have Debian installed with the discard option which means I don't have to run any trim commands at all as it happens automatically, if I've understood it correctly. I also noticed that some drives has trouble with the discard option or using trim. I use Crucial which is one of them. Could someone shed some light on this please?
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

Re: New SSD

#7 Post by ticojohn »

phenest wrote:
sjukfan wrote:Who knows, maybe some biological kind of disks that save the data in proteins? :D
You watch too much Star Trek.

What is the need for trim once a week? I have Debian installed with the discard option which means I don't have to run any trim commands at all as it happens automatically, if I've understood it correctly. I also noticed that some drives has trouble with the discard option or using trim. I use Crucial which is one of them. Could someone shed some light on this please?
From what I read, using discard will slow down your drive access in that it automatically runs a trim type of operation every time you delete a file, so during that time your access is limited. That's if I understand correctly what is happening with discard.
I am not irrational, I'm just quantum probabilistic.

User avatar
bw123
Posts: 4015
Joined: 2011-05-09 06:02
Has thanked: 1 time
Been thanked: 28 times

Re: [SOLVED] New SSD

#8 Post by bw123 »

From what I read, using discard will slow down your drive access in that it automatically runs a trim type of operation every time you delete a file, so during that time your access is limited. That's if I understand correctly what is happening with discard.
When mounting without 'discard' if files are marked deleted, but not freed up to the drive controller until 'fstrim' is run per cron or other schedule, what will be the impact on the drive "garbage collection" and other housekeeping?

I have seen one source that discard is slower when deleting thousands of files with an actual test of one specific drive. But the idea that discard is slower in general use doesn't have much evidence I have found. On the other hand, there's practically no mention of what the drive controller thinks about having gigs of space suddenly freed up by a weekly or monthy fstrim.

I like a good discussion, the fstrim -vs- discard thing is all over the net, with the 'performance' argument winning almost every time.
resigned by AI ChatGPT

User avatar
pylkko
Posts: 1802
Joined: 2014-11-06 19:02

Re: [SOLVED] New SSD

#9 Post by pylkko »

Also, I believe some drives/firmware suffered from problems/bugs with discard, which didn't apply to fstrim. This is mentioned in the Debian wiki and it even links to kernel code where in the comments you can see which versions of which firmware have what problems. I have also seen measurement/benchmarks on the net that claim significant slowdowns with discard. However, it might be that most of those issue are gone with firmware updates :?:

Using the timer method you can guarantee that everytime it is done the machine will not be in use. I don't see what difference it makes to do it all at once or in shorter units, but if you are unwilling to do it once a week, with the timer you can choose any interval that you want. So, I would say that taking all of this into account, the timer method wins hands down no contest.

User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

Re: [SOLVED] New SSD

#10 Post by ticojohn »

pylkko wrote: Using the timer method you can guarantee that everytime it is done the machine will not be in use. I don't see what difference it makes to do it all at once or in shorter units, but if you are unwilling to do it once a week, with the timer you can choose any interval that you want. So, I would say that taking all of this into account, the timer method wins hands down no contest.
I suppose that all might be really important on a production machine, but for a personal computer I find just doing trim once a week is pretty painless. It takes probably less than a minute for my Samsung 950 Pro nvme device. It's pretty easy to find a minute a week. But yeah, stay away from discard.
I am not irrational, I'm just quantum probabilistic.

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: [SOLVED] New SSD

#11 Post by phenest »

bw123 wrote:I have seen one source that discard is slower when deleting thousands of files with an actual test of one specific drive. But the idea that discard is slower in general use doesn't have much evidence I have found. On the other hand, there's practically no mention of what the drive controller thinks about having gigs of space suddenly freed up by a weekly or monthy fstrim.
I don't do a lot of deleting, so the impact must be minimal and certainly not noticeable.
pylkko wrote:Also, I believe some drives/firmware suffered from problems/bugs with discard, which didn't apply to fstrim. This is mentioned in the Debian wiki and it even links to kernel code where in the comments you can see which versions of which firmware have what problems.
The Wiki says discard/trim. Why is fstrim not affected?
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

Re: [SOLVED] New SSD

#12 Post by ticojohn »

phenest wrote:
bw123 wrote:I have seen one source that discard is slower when deleting thousands of files with an actual test of one specific drive. But the idea that discard is slower in general use doesn't have much evidence I have found. On the other hand, there's practically no mention of what the drive controller thinks about having gigs of space suddenly freed up by a weekly or monthy fstrim.
I don't do a lot of deleting, so the impact must be minimal and certainly not noticeable.
pylkko wrote:Also, I believe some drives/firmware suffered from problems/bugs with discard, which didn't apply to fstrim. This is mentioned in the Debian wiki and it even links to kernel code where in the comments you can see which versions of which firmware have what problems.
The Wiki says discard/trim. Why is fstrim not affected?
You may not do a lot of deleting, but every time you modify a file, and that file changes size,you may be physically placing the file contents in a different location which then is generating unused space on the drive. that space will then be freed automatically by the discard function. That, in itself, will cause a lot of extra writes to the SSD as it frees up that space. Plus, while discard is in process your disc access is going to be slowed down. Using fstrim once a week will greatly reduce the amount of disc activity. At least that is my perception of the differences in discard and fstrim. I may be wrong. Wouldn't be the first, or last, time.
I am not irrational, I'm just quantum probabilistic.

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: New SSD

#13 Post by phenest »

Head_on_a_Stick wrote:EDIT: more opinions can be found in this thread:

http://forums.debian.net/viewtopic.php?f=17&t=130615
That thread is quite enlightening.

So, discard is a kernel option that issues a TRIM command immediately, whereas fstrim issues the TRIM command whenever you choose to. However, not all SSD's support the TRIM command which is why there is specific code in the kernel to deal with this. SSD's that do not support the TRIM command are not "buggy", it's just they have garbage collection functionality that means TRIM is not needed. It also means that if your SSD does not support TRIM, then fstrim is also a pointless exercise.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
pylkko
Posts: 1802
Joined: 2014-11-06 19:02

Re: New SSD

#14 Post by pylkko »

except that as the kernel code states, some are/were indeed buggy...

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: [SOLVED] New SSD

#15 Post by phenest »

pylkko wrote:Also, I believe some drives/firmware suffered from problems/bugs with discard, which didn't apply to fstrim.
How do you know it doesn't apply to fstrim?
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
ticojohn
Posts: 1284
Joined: 2009-08-29 18:10
Location: Costa Rica
Has thanked: 21 times
Been thanked: 44 times

Re: New SSD

#16 Post by ticojohn »

phenest wrote:
Head_on_a_Stick wrote:EDIT: more opinions can be found in this thread:

http://forums.debian.net/viewtopic.php?f=17&t=130615
That thread is quite enlightening.

So, discard is a kernel option that issues a TRIM command immediately, whereas fstrim issues the TRIM command whenever you choose to. However, not all SSD's support the TRIM command which is why there is specific code in the kernel to deal with this. SSD's that do not support the TRIM command are not "buggy", it's just they have garbage collection functionality that means TRIM is not needed. It also means that if your SSD does not support TRIM, then fstrim is also a pointless exercise.
So, you buy SSD with TRIM support. Easy choice.
I am not irrational, I'm just quantum probabilistic.

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: New SSD

#17 Post by phenest »

ticojohn wrote:
phenest wrote:
Head_on_a_Stick wrote:EDIT: more opinions can be found in this thread:

http://forums.debian.net/viewtopic.php?f=17&t=130615
That thread is quite enlightening.

So, discard is a kernel option that issues a TRIM command immediately, whereas fstrim issues the TRIM command whenever you choose to. However, not all SSD's support the TRIM command which is why there is specific code in the kernel to deal with this. SSD's that do not support the TRIM command are not "buggy", it's just they have garbage collection functionality that means TRIM is not needed. It also means that if your SSD does not support TRIM, then fstrim is also a pointless exercise.
So, you buy SSD with TRIM support. Easy choice.
Why?
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: [SOLVED] New SSD

#18 Post by phenest »

Taken from http://forum.crucial.com/t5/Crucial-SSD ... a-p/100276
Recently we’ve received multiple calls about the TRIM feature and how it relates to Crucial SSDs. In a nutshell, TRIM is a feature that helps increase the efficiency of your SSD by preparing data blocks for reuse. Here’s how it works.

TRIM and Data Blocks

On hard drives and SSDs, data is stored in blocks (“data blocks”). Each data block has data from more than one file, and on a hard drive the blocks can be split whenever necessary. When you delete a file in your operating system, for example, the hard drive deletes only that specific file’s information from the data block, leaving the rest in place. When a file is deleted in the computer’s file system, the data stays on the block until the next time that block is needed. At that point the drive swiftly deletes that particular piece of data from that part of the block, and writes the new file there. Essentially, hard drives are able to delete information from part of a data block – they don’t have to delete the whole thing.

In contrast, SSDs have to delete an entire data block before they’re able to reuse it. As such, when an SSD is trying to clear a data block, it puts a copy of everything on the block into a cache (“holding place”) and makes the necessary changes there. The SSD then deletes all of the data on the original block and writes the new data that it was trying to write in the first place.

Understandably, going through all these steps takes a lot longer than it would have taken to simply write data to an empty block. Since the SSD knows this, it simply locates an empty block and writes there. This works great – as long as empty blocks are still available on the drive. When all of the blocks are filled up, the SSD has no choice but to start deleting blocks and reusing them, resulting in a drop in write speeds. This problem, however, can be overcome with TRIM – a feature that prompts the SSD to clear previously used data blocks. With TRIM, the next time an SSD’s filing system wants to write to those blocks, they are already empty and ready for use.
And now the the part specific to Crucial SSD's...
Crucial SSDs and TRIM/Garbage Collection

Since not all operating systems support TRIM, Crucial SSDs have a special feature called Active Garbage Collection. Active Garbage Collection is a process that helps an SSD maintain optimal performance by freeing up memory sectors that are no longer in use. Garbage collection is part of the SSD itself and thus not dependent on your computer’s operating system. Since garbage collection is part of the SSD’s firmware, it works regardless of which operating and filing systems your computer is using.

Note: Garbage collection only works when your Crucial SSD is idle, so make sure to configure your system so it doesn’t go to sleep when it’s idling. Garbage Collection takes time to do its job, but as long as it gets time to idle every now and then, your Crucial SSD will maintain its high level of performance over time.
It's possible other manufacturers do something similar.

In a nutshell, I would say that manufacturers have already responded to performance issues using built-in functionality that requires no OS intervention. In which case, unless you're running a server or have little empty space left for example, TRIM isn't an issue.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

Post Reply