[SOLVED] New SSD

Here you can discuss every aspect of Debian. Note: not for support requests!

[SOLVED] New SSD

Postby ticojohn » 2016-11-26 23:45

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'm not irrational, I'm just quantum probabilistic.
User avatar
ticojohn
 
Posts: 612
Joined: 2009-08-29 18:10
Location: Costa Rica

Re: New SSD

Postby emariz » 2016-11-27 04:10

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.
emariz
 
Posts: 2881
Joined: 2008-10-17 07:59

Re: New SSD

Postby Head_on_a_Stick » 2016-11-27 10:30

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:

viewtopic.php?f=17&t=130615
“Such is modern computing: everything simple is made too complicated because it’s easy to fiddle with; everything complicated stays complicated because it’s hard to fix." — Rob Pike

Please read before posting How to report a problem
User avatar
Head_on_a_Stick
 
Posts: 6419
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: New SSD

Postby ticojohn » 2016-11-28 14:20

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'm not irrational, I'm just quantum probabilistic.
User avatar
ticojohn
 
Posts: 612
Joined: 2009-08-29 18:10
Location: Costa Rica

Re: New SSD

Postby sjukfan » 2016-11-28 15:30

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
Debian Stretch AMD64, Core 2 Quad Q9550
Debian Jessie ARM, NSLU2 Intel IXP420
Debian Sid Powerpc, PowerPC 7447a
User avatar
sjukfan
 
Posts: 354
Joined: 2010-03-01 19:39

Re: New SSD

Postby phenest » 2016-11-28 16:46

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?
Dell XPS 17 L702X i7 2860QM 2.5GHz - 32GB RAM - 4G WWAN - Pioneer TD05-BDR
NEC Spirit 550 P4 3.6GHz HT - 2GB RAM - nVidia 7600GT - Pioneer BDR-209DBK
ASUS P8P67 EVO i7 3770K - 32GB RAM - 2x nVidia 660GTX SLI'd
User avatar
phenest
 
Posts: 1157
Joined: 2010-03-09 09:38
Location: The Matrix

Re: New SSD

Postby ticojohn » 2016-11-28 18:01

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'm not irrational, I'm just quantum probabilistic.
User avatar
ticojohn
 
Posts: 612
Joined: 2009-08-29 18:10
Location: Costa Rica

Re: [SOLVED] New SSD

Postby bw123 » 2016-11-28 19:26

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.
jessie/KDE4.14.2 plasma netbook, 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
User avatar
bw123
 
Posts: 2378
Joined: 2011-05-09 06:02
Location: TN_USA

Re: [SOLVED] New SSD

Postby pylkko » 2016-11-28 19:48

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
pylkko
 
Posts: 855
Joined: 2014-11-06 19:02

Re: [SOLVED] New SSD

Postby ticojohn » 2016-11-29 01:00

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'm not irrational, I'm just quantum probabilistic.
User avatar
ticojohn
 
Posts: 612
Joined: 2009-08-29 18:10
Location: Costa Rica

Re: [SOLVED] New SSD

Postby phenest » 2016-11-29 16:44

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?
Dell XPS 17 L702X i7 2860QM 2.5GHz - 32GB RAM - 4G WWAN - Pioneer TD05-BDR
NEC Spirit 550 P4 3.6GHz HT - 2GB RAM - nVidia 7600GT - Pioneer BDR-209DBK
ASUS P8P67 EVO i7 3770K - 32GB RAM - 2x nVidia 660GTX SLI'd
User avatar
phenest
 
Posts: 1157
Joined: 2010-03-09 09:38
Location: The Matrix

Re: [SOLVED] New SSD

Postby ticojohn » 2016-12-07 14:05

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'm not irrational, I'm just quantum probabilistic.
User avatar
ticojohn
 
Posts: 612
Joined: 2009-08-29 18:10
Location: Costa Rica

Re: New SSD

Postby phenest » 2016-12-07 17:33

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

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.
Dell XPS 17 L702X i7 2860QM 2.5GHz - 32GB RAM - 4G WWAN - Pioneer TD05-BDR
NEC Spirit 550 P4 3.6GHz HT - 2GB RAM - nVidia 7600GT - Pioneer BDR-209DBK
ASUS P8P67 EVO i7 3770K - 32GB RAM - 2x nVidia 660GTX SLI'd
User avatar
phenest
 
Posts: 1157
Joined: 2010-03-09 09:38
Location: The Matrix

Re: New SSD

Postby pylkko » 2016-12-07 17:35

except that as the kernel code states, some are/were indeed buggy...
User avatar
pylkko
 
Posts: 855
Joined: 2014-11-06 19:02

Re: [SOLVED] New SSD

Postby phenest » 2016-12-07 18:23

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?
Dell XPS 17 L702X i7 2860QM 2.5GHz - 32GB RAM - 4G WWAN - Pioneer TD05-BDR
NEC Spirit 550 P4 3.6GHz HT - 2GB RAM - nVidia 7600GT - Pioneer BDR-209DBK
ASUS P8P67 EVO i7 3770K - 32GB RAM - 2x nVidia 660GTX SLI'd
User avatar
phenest
 
Posts: 1157
Joined: 2010-03-09 09:38
Location: The Matrix

Next

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 6 guests

fashionable