Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [EN] SSD : Special area in installer ?!  (Read 4986 times)

Offline rueX

  • User
  • Posts: 135
[EN] SSD : Special area in installer ?!
« on: 2013/06/07, 20:27:18 »
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 !


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...


is there an english - version around - for all ?

Would it be an idea - for siduction installer ?

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.847
SSD : Special area in installer ?!
« Reply #1 on: 2013/06/07, 21:57:28 »
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.


Offline rueX

  • User
  • Posts: 135
SSD : Special area in installer ?!
« Reply #2 on: 2013/06/08, 11:44:23 »
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


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

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.847
SSD : Special area in installer ?!
« Reply #3 on: 2013/06/08, 12:40:50 »
Definitely you will need discard. That enables TRIM to remove, whatever the garbage-collection found deletable.



  • Guest
SSD : Special area in installer ?!
« Reply #4 on: 2013/06/08, 15:39:16 »
Some use the commit=600 option in fstab:

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!

Offline dibl

  • siduction community member
  • Global Moderator
  • User
  • *****
  • Posts: 2.379
    • Land of the Buckeye
SSD : Special area in installer ?!
« Reply #5 on: 2013/06/08, 17:59:34 »
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:

After double-clicking the new string, we assign it the value:

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:

mkdir "$NEWDIR" &
sleep 1
mkdir "$NEWDIR1" &
sleep 1
mkdir "$NEWDIR2" &

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.
System76 Oryx Pro, Intel Core i7-11800H, SSD 970 EVO Plus;  Asus ROG STRIX X299-E, Core i7-7740X, Nvidia GTX-1060, dual monitors, SSD 860 EVO