Nieuws:

Welkom, Gast. Alsjeblieft inloggen of registreren.
Heb je de activerings-mail niet ontvangen?

Auteur Topic: Aanpassingen voor SSD  (gelezen 2515 keer)

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Aanpassingen voor SSD
« Gepost op: 2015/02/28, 18:44:33 »
Omdat een SSD maar een beperkt aantal malen herschrijfbaar is, heb ik een aantal dingen aangepast volgens de website van Pjotr.
Alleen is er toch een probleem, waarnaar ik ook gezocht heb op internet, maar ik kom er niet uit.
De bedoeling is, dat log-files en tmp-files in het ram geheugen worden opgeslagen.
Hiertoe moet het volgende onderaan de /etc/fstab file staan:
# Aanpassing voor SSD
tmpfs      /var/log        tmpfs      defaults,noatime        0    0
tmpfs      /tmp          tmpfs      defaults,noatime,mode=1777    0    0

Wanneer ik dit doe, werkt de apache2 server niet meer.
Heeft iemand enig idee waar het fout gaat?

Edit: De fout moet in de eerste blauwe regel zitten ........
« Laatst bewerkt op: 2015/02/28, 19:12:39 door Ron »
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline jan11000

  • Lid
Re: Aanpassingen voor SSD
« Reactie #1 Gepost op: 2015/02/28, 18:46:04 »
1777
Is dit goed?

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #2 Gepost op: 2015/02/28, 18:52:34 »
1777
Is dit goed?
RW voor iedereen, moet goed zijn........
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline jan11000

  • Lid
Re: Aanpassingen voor SSD
« Reactie #3 Gepost op: 2015/02/28, 18:53:57 »
Moet dat niet 777 zijn.
1777 lijkt toch goed te zijn.

Tegenwoordig hoef je niks in het geheugen te zetten voor een ssd, ze gaan zeer lang mee, dus niet nodig.
Wel controleren of trim werkt, want dat zou de snelheid naar beneden halen.
« Laatst bewerkt op: 2015/02/28, 18:58:49 door jan11000 »

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #4 Gepost op: 2015/02/28, 19:11:32 »
Wel controleren of trim werkt, want dat zou de snelheid naar beneden halen.
Is daar een Nederlandstalige uitleg voor?
Wanneer ik het mag geloven, zou het automatisch moeten werken bij versie 13.10 en hoger.
De Micro-SSD ondersteund het ook, anders wachten we maar rustig af ........

Voorlopig is hij bloedsnel, opstarten (na grub) in 6 seconden en bij iedere reboot een fout-melding, dat er geen Wifi is, en 3 seconden later de melding dat hij een Wifi verbinding heeft.
De router reageert nu te traag voor deze snelle klaptop :lol:
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline testcees

  • Documentatieteam
    • testcees
    • www.testcees.nl
Re: Aanpassingen voor SSD
« Reactie #5 Gepost op: 2015/02/28, 19:20:36 »
Omdat een SSD maar een beperkt aantal malen herschrijfbaar is,
Een SSD is juist heel vaak herschrijfbaar en zelfs als je logbestanden wegschrijft kan het wel 40 jaar duren voor dat het maximum is bereikt.
I mean if you write say 10 GB a day / 365 days a year that would be 3.7 TB per year. So that's like 40 years of lifespan easily.
Wanneer ik dit doe, werkt de apache2 server niet meer.
Heeft iemand enig idee waar het fout gaat?
Heb je al in /var/log/apache2 gekeken of er een foutmelding is gelogd?
Of is juist het probleem dat apache de log niet kan wegschrijven omdat er geen /var/log/apache2/ is in tmpfs?  :P
Klik links bovenin op Documentatie

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #6 Gepost op: 2015/02/28, 19:36:26 »
Het laatste Cees ......
Maar voorlopig maak ik mij nog geen zorgen, binnen de garantie-termijn zal deze zeker niet defect raken, neem ik aan.
De data staat niet op de SSD, daarvoor heb ik (ook nog) een 1TB hardeschijf er in zitten.
Alleen de websites die ik maak staan wel op de SSD, maar dat is simpel na een verandering naar de HD te kopiëren ........
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline testcees

  • Documentatieteam
    • testcees
    • www.testcees.nl
Re: Aanpassingen voor SSD
« Reactie #7 Gepost op: 2015/02/28, 19:47:04 »
De data staat niet op de SSD, daarvoor heb ik (ook nog) een 1TB hardeschijf er in zitten.
Alleen de websites die ik maak staan wel op de SSD, maar dat is simpel na een verandering naar de HD te kopiëren ........
Voor een website zou ik de logs even bewaren en dus niet in tmpfs plaatsen zodat je later nog kan terugkijken bij problemen maar die keuze is aan jou.

Eventueel kan je logs wegschrijven op de HD als die ook aanwezig is (maar nogmaals dat zal geen merkbaar verschil opleveren).
Klik links bovenin op Documentatie


Re: Aanpassingen voor SSD
« Reactie #9 Gepost op: 2015/02/28, 21:25:41 »
/var/log in RAM zetten heeft wel een risiko (met name icm Apache 2.... ;) ):
Citaat
Auch die Verlagerung von /var/log ins RAM sollte man sorgfältig abwägen, ob der geringfügige Vorteil durch die Verringerung der Schreibvorgänge die Nachteile aufwiegt, da bei jedem Herunterfahren bzw. Neustart sämtliche Logdateien des Systems unwiederbringlich verloren gehen.

/var/log im RAM bedeutet:
    eingeschränkte Möglichkeiten zu Fehlerverfolgung (insbesondere nach Systemabstürzen)
    keine Möglichkeit zur nachträglichen Analyse von Sicherheitsvorfällen
    Von Paketen während der Installation erstellte Unterverzeichnisse gehen verloren

Verwenden installierte Programmpakete Unterverzeichnisse, wie beispielsweise Samba, so fehlen sämtliche Logdateien dafür. Schlimmer ist es etwa bei Apache 2: Der Start schlägt beim Versuch fehl, die Datei error.log zu öffnen. Erst das Erstellen des Unterverzeichnis mit den entsprechenden Rechten behebt das Problem.

Citaat
There is one drawback for /var/log: The log doesn't survive reboots. If there are any problems of system freeze to track down /var/log has to be put on disk.


En zoals anderen al aangaven: ik zou mij niet zo druk maken om de levensduur van (recente!) SSD's en vanalles in het RAM laden (met het risiko op problemen tijdens een (al dan niet gewenste) reboot.
« Laatst bewerkt op: 2015/02/28, 21:39:21 door VuurVosje »

Offline aartje

  • Lid
Re: Aanpassingen voor SSD
« Reactie #10 Gepost op: 2015/03/01, 09:48:56 »
Ik heb de computer (zonder die tmpfs aanpassingen in je /etc/fstab) opgestart
en daarna /var/spool als volgt in een tgz-file gezet:

cd /var/spool
sudo tar -zcvf /VAR_SPOOL.tgz .

Daarna heb ik in /etc/rc.local aan het eind (voor "exit 0") het volgende erbij
gezet:

cd /var/spool
tar -zxpf /VAR_SPOOL.tgz
fstrim -v /
fstrim -v /rootub1204ssd
fstrim -v /datassdext4
fstrim -v /datassdext4b
exit 0

Ik doe dus hier ook iedere keer bij het opstarten een fstrim op alle ssd-partities
die gemount worden in mijn systeem (Mint17 en Ubuntu 12.04).
"exit 0" staat er ook bij aan het eind, maar die staat er volgens mij al in.
Daarna je fstab aan passen. Bij mij is er het volgende aan toegevoegd:

tmpfs   /tmp               tmpfs   defaults,noatime,size=1G,mode=1777  0 0
tmpfs   /var/log          tmpfs   defaults,noatime,mode=1777 0 0
tmpfs   /var/tmp         tmpfs   defaults,noatime,mode=1777 0 0
tmpfs   /var/log/apt   tmpfs   defaults,noatime 0 0
tmpfs   /var/spool     tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/cache/apt/archives  tmpfs  defaults,noatime,mode=1777 0 0

Daarna je systeem herstarten.


Misschien helpt dit.
« Laatst bewerkt op: 2015/03/01, 09:51:30 door aartje »

Re: Aanpassingen voor SSD
« Reactie #11 Gepost op: 2015/03/01, 10:27:41 »
tmpfs   /tmp               tmpfs   defaults,noatime,size=1G,mode=1777  0 0
tmpfs   /var/log          tmpfs   defaults,noatime,mode=1777 0 0
tmpfs   /var/tmp         tmpfs   defaults,noatime,mode=1777 0 0
tmpfs   /var/log/apt   tmpfs   defaults,noatime 0 0
tmpfs   /var/spool     tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/cache/apt/archives  tmpfs  defaults,noatime,mode=1777 0 0

Ik zou hier erg voorzichtig mee zijn (en het zeker niet zomaar aan anderen adviseren); daar zitten een aantal bij die bedoeld zijn om een reboot te overleven...
http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE
Citaat
/var/tmp : Temporary files preserved between system reboots
Purpose

The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.

Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.
Citaat
tmpfs   /var/spool     tmpfs defaults,noatime,mode=1777 0 0
Volgens mij staan hier de cronjobs: die ben je dan kwijt.
Maar correct me if I'm wrong.

Citaat
tmpfs   /tmp               tmpfs   defaults,noatime,size=1G,mode=1777  0 0
Ook niet zomaar adviseren: je limiteert tmp op 1G. Als iemand zware apps draait die meer dan 1G nodig hebben breng je hem in de problemen.
Bv DVD branden.
Dat is precies het nadeel: je weet niet hoeveel RAM iemand heeft en wat hij/zij met zijn pc doet, daarom niet zomaar adviseren. 


Overigens waarom zowel  /var/log als /var/log/apt en /var/spool; werkt dit niet recursief?
Idem fstrim?


En de hamvraag: wat bereik je hiermee? En is de risiko's waard?  :)
Tenzij je iets héééél bijzonders hebt in je systeem en een antieke SSD, is er geen reden (meer) om dit te doen.

« Laatst bewerkt op: 2015/03/01, 10:40:41 door VuurVosje »

Offline Johan van Dijk

  • Administrator
    • johanvandijk
Re: Aanpassingen voor SSD
« Reactie #12 Gepost op: 2015/03/01, 11:16:11 »
Dat is inderdaad geen goed advies. Dus niet zomaar uitvoeren.

De standaardinstellingen van Ubuntu en Mint zijn niet perfect maar voldoen prima voor normaal gebruik. Eventueel kan je een fstrim inplannen 1x per week op een moment waarvan je weet dat je computer dan niet zoveel te doen heeft, maar daar zou ik het verder bij laten. Alle overige "tweaks" leveren in theorie wel wat besparing op de hoeveelheid data die geschreven wordt, maar hebben allemaal ook flinke nadelen waar je goed rekening mee moet houden. En die besparingen zijn niet wereldschokkend groot dus hoe groot je voordeel is ten opzichte van de nadelen valt nog te bezien...

Heb je een bijzondere situatie waarin je van tevoren al weet dat je tientallen/honderden gigabytes per dag gaat schrijven dan kan je daar rekening mee houden door die te verplaatsen naar een paar harde schijven. Maar als je in die situatie zit doe je er beter aan om zelf eerst goed uit te zoeken wat bij je systeem past en is bijna al het willekeurige advies wat je op internet tegenkomt alleen maar contraproductief.

Offline Pjotr

  • Lid
    • Makkelijke Linuxtips
Re: Aanpassingen voor SSD
« Reactie #13 Gepost op: 2015/03/01, 11:33:26 »
Tja, zelf heb ik al ruim twee jaar een druk gebruikte bureaucomputer met alleen een SSD erin als "harde schijf", en nog nimmer problemen gehad door /var/log en /tmp in het RAM te plaatsen (uitsluitend die twee, overigens).

Wel met een aanpassing in /etc/rc.local, om bij opstart de mapstructuur te herstellen in /var/log, zoals ook beschreven in mijn handleiding:
#
# Aanpassing voor SSD
for dir in apparmor apt cups dist-upgrade fsck gdm installer samba unattended-upgrades ;
do
           if [ ! -e /var/log/$dir ] ; then
                   mkdir /var/log/$dir
           fi
done

Zie:
https://sites.google.com/site/computertip/ssd

Maar ik denk er al een tijdje over, om althans de verplaatsing van /var/log te schrappen. Hoewel die, zoals gezegd, bij mij absoluut niet tot problemen leidt, is het toch een vrij gekunstelde oplossing die heden ten dage niet echt nuttig meer lijkt te zijn voor een SSD.
« Laatst bewerkt op: 2015/03/01, 11:37:27 door Pjotr »

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #14 Gepost op: 2015/03/01, 11:39:03 »
Op dit moment lijkt alles goed en snel te werken, met de volgende opties:
In fstab:UUID=790ca9cc-fbc0-4970-8049-494c1c812482 /               ext4    noatime,errors=remount-ro 0       1in rc.local:for dir in apparmor apt cups dist-upgrade fsck gdm installer samba unattended-upgrades ;
do
           if [ ! -e /var/log/$dir ] ; then
                   mkdir /var/log/$dir
           fi
done
fstrim -v /
exit 0
En in sysctl.conf:#
# Verminder de swapneiging ten zeerste
vm.swappiness=1
# Krimp de inode cache niet agressief in
vm.vfs_cache_pressure=50
Dit lijkt te werken, begrijpen doe ik het niet helemaal, met name rc.local :lol:
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline Pjotr

  • Lid
    • Makkelijke Linuxtips
Re: Aanpassingen voor SSD
« Reactie #15 Gepost op: 2015/03/01, 12:15:03 »
Wat die aanpassing in rc.local betreft: daarmee herstel je telkens bij opstart, de mapstructuur die het systeem verwacht aan te treffen in /var/log.  :)

Offline Nero

  • Lid
Re: Aanpassingen voor SSD
« Reactie #16 Gepost op: 2015/03/01, 12:27:37 »
rc.localcd /var/log
mkdir -p apparmor apt cups dist-upgrade fsck gdm installer samba unattended-upgrades
Is dit niet sneller?
Nadeel tov de for-loop?

Offline Johan van Dijk

  • Administrator
    • johanvandijk
Re: Aanpassingen voor SSD
« Reactie #17 Gepost op: 2015/03/01, 12:36:13 »
Dit heeft alleen zin als je /var/log in het geheugen opslaat (want op je SSD zou alles blijven staan en is dit niet nodig). En je geheugen is zo snel dat het misschien enkele nanoseconden scheelt in snelheid.
Theoretisch is het dus wel sneller, in de praktijk niet echt.

Nog een mogelijk probleempunt is dat niet alle mappen de juiste rechten krijgen. Bijv. de cups map hoort van de lpadmin groep te zijn, en niet root:root en zo zijn er nog meer verschillen. Het is dus mogelijk dat je niet kan printen omdat cups niet aan de logbestanden mag komen.

Je bent ook al je logbestanden kwijt bij een reboot. En als die onverwacht gebeurde kan je niet uitzoeken wat de oorzaak was....

En met deze truc bespaar je hooguit enkele tientallen megabytes per dag. Dat maakt voor de levensduur van je SSD geen moer uit (zie de reactie van testcees eerder).

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #18 Gepost op: 2015/03/01, 12:41:03 »
In dat geval, is voor rc.local dus alleen het volgende nodig:
fstrim -v /
exit 0
Het wordt wel steeds simpeler, straks hoef ik niets meer te doen :lol:
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline Johan van Dijk

  • Administrator
    • johanvandijk
Re: Aanpassingen voor SSD
« Reactie #19 Gepost op: 2015/03/01, 12:42:04 »
De -v optie kan je ook nog weglaten, dat scheelt weer een melding bij het opstarten en in je logboeken ;)

Offline aartje

  • Lid
Re: Aanpassingen voor SSD
« Reactie #20 Gepost op: 2015/03/01, 12:59:53 »
Met mij SSD heb ik alleen de fstab veranderd en dat trim gebeuren aangepast. Meer niet. Oh, ik vergeet de swappenes.

Ik zelf vind het echt overkill als je zoveel nog zou moeten veranderen in bepaalde files voor een SSDtje. Zeker voor mensen die niet weten hoe dat allemaal werkt, vind ik eh......overbodig.
Ja, daar ben ik het mee wel mee eens. Ik heb al die aanpassingen gedaan om dat het niets kost en ik het
wel elegant vind als er zo min mogelijk op de SSD geschreven wordt. Ik heb nu in een paar jaar tijd er totaal geen problemen
mee gehad, ook niet met /var/tmp in geheugen en zo.

Maar aan de andere kant zijn controllers vande SSD's zo intelligent dat eigenlijk al die aanpassingen niet nodig zijn (op de fstrim en/of
discard in de fstab na dan).
Ik geloof dat je voor mijn SSD (Samsung 830 128GB) 5 jaar lang iedere dag gemiddeld 20 GB moet schrijven voor je
er iets van merkt. Ik kan me niet voorstellen dat een normale gebruiker die waardes haalt.
Verder heb ik helemaal niet op de modes gelet die op die directories gezet moeten worden. Dat is ook
niet nodig als je het op de manier van mij doet, met een " cd /var/spool ; tar -zxf /VAR_SPOOL.tgz" in je
/etc/rc.local
« Laatst bewerkt op: 2015/03/01, 13:05:17 door aartje »

Offline aartje

  • Lid
Re: Aanpassingen voor SSD
« Reactie #21 Gepost op: 2015/03/01, 13:11:33 »
Ik zelf heb ook een Samsung SSD 120 gb. en met deze weinige aanpassingen heb ik nog nooit een probleem gehad.
Mijn werkpc heeft dezelfde SSD en ook bij deze heel weinig aanpassingen gedaan. Nooit problemen!

Dus dan denk ik, waarom zo veel aanpassingen terwijl dat mss helemaal niet nodig is. En dat het overkill is.
Ben ik eigenlijk mee eens  :rolleyes:

Offline Pjotr

  • Lid
    • Makkelijke Linuxtips
Re: Aanpassingen voor SSD
« Reactie #22 Gepost op: 2015/03/01, 16:51:39 »
Goed om 't hier weer eens over te hebben; met name dank aan Johan en Vuurvosje voor de technische onderbouwing.

Ik had de verplaatsing van /var/log en /tmp al enige tijd geleden in m'n SSD-handleiding afgewaardeerd naar "Optioneel". Maar wegens het beperkte nut dat deze verplaatsing tegenwoordig nog maar heeft, heb ik 'm zojuist geheel uit de SSD-handleiding verwijderd.

Daarmee wordt de SSD-handleiding ook vereenvoudigd, wat eveneens winst is.

Offline Ron

  • Forumteam
    • r0n
    • Over Tholen
Re: Aanpassingen voor SSD
« Reactie #23 Gepost op: 2015/03/01, 18:59:54 »
Zojuist een schone installatie gedaan, ik ga je pagina lezen .......

Edit:
Nu staat er fstrim -v / met eventueel een extra regel voor een aparte /home e.d.
Is het dan niet makkelijker om gewoon fstrim -a te doen? (-a = all, dus alle gemounte partities)?
« Laatst bewerkt op: 2015/03/01, 19:21:40 door Ron »
Openstandaard Evangelist, OpenSource Promotor, OpenData voorstander.
Xubuntu gebruiker en voorstander
Er is ook nog een andere hobby.

Offline aartje

  • Lid
Re: Aanpassingen voor SSD
« Reactie #24 Gepost op: 2015/03/01, 23:53:39 »
Zojuist een schone installatie gedaan, ik ga je pagina lezen .......

Edit:
Nu staat er fstrim -v / met eventueel een extra regel voor een aparte /home e.d.
Is het dan niet makkelijker om gewoon fstrim -a te doen? (-a = all, dus alle gemounte partities)?
Als ik "man fstrim" doe zie ik niet dat er een -a argument kan worden gegeven (mint17)


fstrim: ongeldige optie -- 'a'

Usage:
 fstrim [options] <mount point>

Opties:
 -h, --help          this help
 -o, --offset <num>  offset in bytes to discard from
 -l, --length <num>  length of bytes to discard from the offset
 -m, --minimum <num> minimum extent length to discard
 -v, --verbose       print number of discarded bytes

For more information see fstrim(8).
« Laatst bewerkt op: 2015/03/01, 23:55:10 door aartje »