[EN] SSD : Special area in installer ?!

[rueX]

Now my system is running fine - with an easy ssd


Well...days later I read the wonderful and great instruction manual from devil ... with special format tips !

http://siduction.org/index.php?module=news&func=display&sid=32

But:
i still "HAVE" installed ...so i wondered, why there was no special area in "siduction-installer" :

It's very important in my opinion:

in german-only-sorry:
"Wichtig ist hier die Zeile:
32 heads, 32 sectors/track, 14593 cylinders
Wenn wir bei fdisk nicht -H 32 -S 32 angegeben hätten, sähe die Zeile so aus:
255 heads, 63 sectors/track, 14593 cylinders und die Partition wäre für das blockweise Löschen einer SSD nicht korrekt ausgerichtet"

...and ...so...on...

similar:
http://wiki.siduction.de/index.php?title=Optimierungen_f%C3%BCr_SSDs

is there an english - version around - for all ?

Would it be an idea - for siduction installer ?

[devil]

all that is done nowadays by gparted and friends. So my howto was more fior the early days of SSD. It does not hurt to follow it, but it is not needed anymore.
I should edit it to reflect that.

greetz
devil

[rueX]

mmmh ?

my SSD:  etc/fstab:

UUID=AFB0-BC1E                                /tmp/partinfo-mount  vfat         auto,users,rw,quiet,umask=000,shortname=lower 0    0  

UUID=85ed9818-62b6-4588-93fa-1ee9dff1502f     /                    ext4         defaults,noatime,errors=remount-ro            0    1  

UUID=737ddba4-c1b8-4dc0-bb15-49d29ae2565d     /media/disk1part3    ext4         auto,users,rw,exec,noatime,discard            0    0  




....and the devil-wiki- recommendation :

devil example :  /etc/fstab:

LABEL=home /home ext4 auto,noatime,discard,defaults   0 0
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

http://wiki.siduction.de/index.php?title=Optimierungen_f%C3%BCr_SSDs




Question: Is my part of my fstab wrong
Which part should i edit - to BOOST LIFETIME  ... ,)

[devil]

Definitely you will need discard. That enables TRIM to remove, whatever the garbage-collection found deletable.

greetz
devil

[zyrox]

Some use the commit=600 option in fstab:
http://wiki.debian.org/SSDOptimization

Another thing is to move log files from disk to ram, or configure rsyslogd to do less logging.

Another tip is to make sure /etc/cron.daily/ doesn't have a mlocate.cron job, or any other job that does a lot of writing to disk. I don't think the debian package for mlocate creates this job so it shouldnt be necessary.



I read some benchmarking results a while ago about SSD disks lifetime and the conclusion was that todays disks will last for a long long time, even longer than many hard disk drives would do so you shouldn't worry about it.
You will only hurt yourself by not using your PC!

[dibl]

If it is a computer that you use for browsing a lot, you can cut down a lot of writes by putting the browser cache in /run/shm.  From the article here (some of this is devil's original blog):

Since we now have the shared directory /run/shm in RAM, we can outsource the cache generated during browsing to memory, and eliminate many SSD writes. For example, in the Firefox/Iceweasel address bar we enter "about:config" and confirm the warning. Now right-click in the white space and choose "New ==> String" and we create a new entry called:

"browser.cache.disk.parent_directory"
After double-clicking the new string, we assign it the value:

"/run/shm/firefox-cache"
Now as user in the terminal create a directory:

mkdir /run/shm/firefox-cache

After a Firefox restart, browser caching happens in memory, not on the SSD.

For chromium-browser, the cache location is set with the “--disk-cache-dir=”DIRNAME” launch command option. So to outsource the chromium-browser cache:

mkdir /run/shm/chromium-cache

Open the chromium-browser launch icon for editing, change to the “Application” tab, and edit the start command to read as follows:

/usr/bin/chromium --disk-cache-dir=/run/shm/chromium-cache %U

The new browser cache directory in /run/shm will not survive a reboot. To automate this process, put the following “auto_browser_cache.sh” script in your ~.kde/Autostart folder (for KDE users), and then “chmod +x” to make it executable:

#!/bin/bash
NEWDIR=/run/shm/username-chromium-cache
mkdir "$NEWDIR" &
sleep 1
NEWDIR1=/run/shm/username-firefox-cache
mkdir "$NEWDIR1" &
sleep 1
NEWDIR2=/run/shm/username-opera-cache
mkdir "$NEWDIR2" &
#end

Analogous cache outsourcing configuration can be made for other browsers, if they allow the user to specify the cache location, and the startup script can be adapted to add directories for each browser that the user wants to run.

For a desktop system that remains booted for long periods, and depending on the memory capacity and browsing activities, the outsourced browsing cache could grow to a problematic size and need to be manually cleared to avoid sending the system into swapping.