Hallo. Ich wollte Debian oder Ubuntu auf einer SSD installieren. SSD's haben ja nur eine begrenzte Zahl von Schreibzugriffen. Wäre es sinnvoll, die Zahl der Schreibzugriffe zu minimieren, indem man hingeht und folgendes macht: -PID Files und ähnliches in eine Ramdisk schreiben -Logs in eine Ramdisk schreiben und nur von Zeit zu Zeit und beim Shutdown auf die SSD oder einen USB Stick sichern -tmp auf USB Stick -Sonstige "Arbeitsverzeichnisse" des Linux System mit sehr häufigen schreibzugriffen ebenfalls auf eine Ramdisk bzw USB Stick auslagern Der USB Stick stellt also quasi das "Verschleißteil" da, um die interne SSD zu schonen. Auf den USB Stick können nur "systemunwichtige" Sachen ausgelagert werden, so dass der Rechner ohne / mit anderem leeren Stick problemlos hochfährt. Was man sonst außer den oben genannten Sachen noch auf Ramdisk oder USB Stick auslagern könnte weiß ich nicht. Gibt bestimmt noch einiges mit vielen Schreibzugriffen, wo ein "Verlust" nicht weiter schlimm ist, da es eh nur "arbeitsdaten" sind bzw jederzeit oder beim Neustart neu generiert werden können. Kennt ihr da noch mehr? Oder würdet ihr diese Arbeit nicht machen und einfach normal auf die SSD installieren, weil die heutigen SSD's dann trotzdem 3-5 Jahre fast-Dauerbetrieb packen würden? mfg
Auch ich hatte zunächst meine Bedenken ob der "Abnutzung" von SSDs. Jedoch habe ich in einer der letzten Ausgaben der ct' einen kurzen Artikel dem Thema gelesen. Langer Rede, kurzer Sinn - die Dinger sind mittlerweile so gut (wear levelling & go), dass sie in Hinsicht auf Lebensdauer / Schreibzugriffe über den sprichwörtlichen Daumen mit den Magnetplatten mithalten können. Vielleicht machst Du Dir daher zu viele Gedanken.
Halbwegs aktuelle SSDs gehen für gewöhnlich in einen Readonly-Modus wenn die Reserveblöcke ausgehen. Via SMART kann man oft auch "SSD Life Left" (oder ähnlich) auslesen was von SMART-Tools als Prozentwert angezeigt wird (nahe 100% = Platte ist quasi neu, Richtung 0% = Bald tot) Anders gesagt: Über irgendwelche Maßnahmen zur Reduktion der Schreibvorgänge würde ich erst nachdenken wenn man nach ner Weile Benutzung via SMART auffällig hohen Verschleiß feststellt...
Nico --- schrieb: > -PID Files und ähnliches in eine Ramdisk schreiben Schadet nichts, bringt aber mangels häufigen Schreibens wenig. > -Logs in eine Ramdisk schreiben und nur von Zeit zu Zeit und beim > Shutdown auf die SSD oder einen USB Stick sichern Wenn die Logs nach Crashs wichtig sind, dann müssen sie auf Platte, weil sie sonst nicht verfügbar sind. Wenn sie unwichtig sind, dann kann man sie drosseln, weglassen oder auf nimmerwiedersehen auf der RAM-Disk lassen. > -tmp auf USB Stick Ein USB-Stick ist für Tempfiles fast so sinnvoll wie eine Floppy-Disk. Weil meistens grauenvoll langsam beim Anlegen/Löschen von Files, was die wohl häufigste Operation in /tmp ist. Nope, das ist der beste Kandidat für eine Linux-typische dynamische RAM-Disk, wenn da nicht grad gigabyteweise Files drauf landen. > Kennt ihr da noch mehr? Was man ziemlich selten benötigt ist die Timestamp für den letzten Zugriff auf eine Directory oder ein File. Jedenfalls ist die für ziemlich viele ziemlich überflüssige Schreibzugriffe verantwortlich und lässt sich beim Mount mühelos abstellen, indem man in die Mount-Optionen von /etc/fstab "noatime" reinschreibt. Benötigt man diese Timestamp von Files, beispielsweise weil man darauf basierende inkrementelle Backups nutzt, dann kann man mit "relatime" immerhin die Häufigkeit reduzieren, evtl. auch ist "nodiratime" machbar. > Oder würdet ihr diese Arbeit nicht machen und einfach normal auf die SSD > installieren, weil die heutigen SSD's dann trotzdem 3-5 Jahre > fast-Dauerbetrieb packen würden? Ich würde es in dieser Frage nicht übertreiben. Bei normaler Nutzung brennt da nichts weg. graue Haare muss man sich deshalb nicht machen.
bluppdidupp schrieb: > die Reserveblöcke ausgehen. Via SMART kann man oft auch "SSD Life Left" > (oder ähnlich) auslesen was von SMART-Tools als Prozentwert angezeigt > wird (nahe 100% = Platte ist quasi neu, Richtung 0% = Bald tot) Ob man aus den SMART Werten irgendwas ableiten kann, und wenn ja wie, ist leider sehr modellspezifisch.
Nico --- schrieb: > Hallo. > > Ich wollte Debian oder Ubuntu auf einer SSD installieren. SSD's haben ja > nur eine begrenzte Zahl von Schreibzugriffen. > Wäre es sinnvoll, die Zahl der Schreibzugriffe zu minimieren, indem man > hingeht und folgendes macht: Warum nicht gleich alles ins Ram legen? RAM ist billiger als eine SSD. Wenn man z.B. 8 GByte RAM installieren kann, spricht nichts dagegen. Bei bis zu 4 GByte RAM sollte man vorher nachdenken, wieviel Platz das Betriebssytem und wieviel Platz die Anwendungen brauchen. Beim Herunterfahren kann man das RAM mit der Platte automatisch synchronisieren lassen. Und falls man nicht synchonisiert, kann man seine Sitzung quasi spurenlos beenden. Das hilft zwar nicht im Fall des Absturzes des Betriebssystemes oder im Fall eines gezielten Hackerangriffes, erhöht aber denoch die praktische Sicherheit erheblich. Man kann einen Mittelweg einschlagen, indem beispielsweise nur Mails, Cookies und Browserhistory synchronisiert werden, was aufwendig, aber machbar ist.
Die Links haben mir dabei sehr geholfen: "Journaling" http://wiki.ubuntuusers.de/Dateisystem "SSD-Partitionierung - erst bei 1MB anfangen und in 1MB Schritten" https://wiki.archlinux.org/index.php/SSD#Tips_for_Maximizing_SSD_Performance "noatime" http://feedblog.org/2008/02/20/ssd-without-noatime-mount-option-considered-harmful-huge-performance-boost/ "noatime,data=writeback,barrier=0" http://blog.smartlogicsolutions.com/2009/06/04/mount-options-to-improve-ext4-file-system-performance/ "noatime für USB-sticks" https://wiki.archlinux.org/index.php/HAL#Enable_the_noatime_mount_option_for_removable_devices "trim, Auslagerungsdatei von Firefox in tmpfs legen" http://www.vanstormbroek.nl/blog/?p=58 "Dateisystem im RAM - tmpfs" http://en.opensuse.org/index.php?title=SDB:SSD_performance&diff=37147&oldid=prev und http://opentechnow.blogspot.com/2010/02/linux-ssd-optimization-guide.html und http://forum.ubuntuusers.de/topic/eintraege-in-fstab-zur-ssd-optimierung-so-kor/#post-2541904 Wenn du deine Programme kompilierst kannst du das auch im tmpfs machen. Ich habe meine workspace-Ordner auf einer normalen Festplatte, die Programme (Eclipse, Code::Blocks, Linux) aber auf der SSD.
Hi. Vielen Dank für die Links, die sind sehr nützlich. Ich will ja einen Linux Router Firewall Proxy / Homewebserver auf Debian Basis einrichten. Es soll ein passiv gekühlter ITX Rechner ohne mechanische Bauteile werden. Also SSD und ordentlich viel Ram (8 GB)
Nico --- schrieb: > Ich will ja einen Linux Router Firewall Proxy / Homewebserver auf > Debian Basis einrichten. Dann nimm Voyage Linux. Fährt im read-only modus hoch, speichert Dateien im RAM und beim herunterfahren wird synchronisiert. Ist von Debian abgeleitet und man kann mit apt-get Programme nachinstallieren. http://linux.voyage.hk Als Rechner kannst Du ein Alix Board nehmen. http://www.alix-board.de
Falls mehr RAM benötigt wird kann es auch dieses Board sein. http://www.heise.de/preisvergleich/432669 Bei mir sind das Betriebssystem und die Daten - je eine Partition - auf einem USB Stick mit SLC Speicher. http://www.simos.de/artikel_uebersicht2.php?KAT=257&LANG=DE#artikel_united-contrast%20v2 http://www.euric.de/mod/Speicherkomponenten-D.htm?id=5&do=shop.show.artikel&ArtikelID=75
Nico --- schrieb: > Ich will ja einen Linux Router Firewall Proxy / Homewebserver auf > Debian Basis einrichten. Es soll ein passiv gekühlter ITX Rechner ohne > mechanische Bauteile werden. Also SSD und ordentlich viel Ram (8 GB) Um 30 - 60 Clients zu versorgen, reicht ein Router mit 0,5 GHz CPU, 0,5 GByte RAM und 1 GByte CF-Card aus. (Falls es noch so kleine CF-Cards gibt.) Eine für 8 GByte RAM passende CPU nebst SSD würde ich zur Versorgung von 1000+ Clients einsetzen. Schlichte Proxies auf dem Router, z.B. für ftp, erhöhen die Anforderungen nicht. Anspruchsvollere Anwendungen auf dem Router, wie Webseiten-Caching, Cryptographie (VPN, IPSEC, AUTH) oder Deep-Package-Inspection setzen vielleicht mehr voraus.
Voyage Linux kannte ich noch gar nicht. Vielen Dank für den Tipp. Muss ich mir mal anschauen. Ich habe bisher nur Debian und Ubuntu intensiver/tiefergehend verwende, daher will ich bei Sachen, wo man selbst hand anlegen muss, gerne auf der Debian Schiene bleiben. Ich habe zwar auch schon verschiedene vorgefertigte Router Distributionen probiert und damit rumgespielt. Aber irgendwas war immer nicht passend und musste durch Rumfrickeln hingebogen werden. Daher will ich jetzt mal mit einem "allgemeinen" Linux probieren, das ich mir passend einrichte. “Voyage is a very stripped-down Debian Linux … With Voyage you have the entire world of Debian available to you, so customizing your own gear is easy. It's great for firewalls and routers, and specialized servers that need a small footprint.” Hört sich gut an. Das mit den Alix boards hört sich auch gut an. Ist nur ein bisschen wenig Ram Drauf. 128 oder 256 Mb, das wird knapp mit dem Squid. Ich wollte ja schon mindestens 1 GB Cache haben. Bei 1 GB Cache braucht er für sich selbst und die Verwaltung schon ca 30-40 Mb ram. Wenn ich dann noch 16 Mb Ram Cache einstelle, wären schon ca 64 MB nur für den Squid weg. Kann man bei den Alix Boads Ram nachrüsten? Mit ordentlich Ram könnte ich den Squid Cache mit 1 GB auch in ner Ramdisk laufen lassen.
Nico --- schrieb: > ich den Squid Cache mit 1 GB auch in ner Ramdisk laufen lassen. Der Nutzen von Webcaching ist heutzutage sehr begrenzt.
Naja, es geht. Bei vielen normalen Webseiten nützt es nichts, da vieles Dynamische Inhalte sind. Aber grade die ganzen Bilder und größeren Objekte die auf Webseiten verwendet werden, können gut gecached werden, da die sehr oft statisch sind. Nicht umsonst gibt es z.B. bei ebay eine eigene Domain, wo nur statischer Content (Die ganzen Bilder z.B.) drüber ausgeliefert werden.
Meine Erfahrung mit einem zentralen Unternehmensproxy sind so um die 20% Hitrate, in Bytes gerechnet. Auf dem outbound proxy für die User, also kein reverse proxy. Die Wahrscheinlichkeit, dass jenseits von ein paar Rahmenbildern viele User im Unternehmen die gleichen ebay-Bilder kriegen ist überschaubar. Bei ebay selbst ist die Situation ein bisschen anders, da ist aus Lastgründen ein separater Server sinnvoll.
naja 20% ist besser als nichts. Bei Youtube scheint der Proxy übrigens auch videos zu cachen. Und Windows Updates werden auch gecached.
Nico --- schrieb: > Mit ordentlich Ram könnte > ich den Squid Cache mit 1 GB auch in ner Ramdisk laufen lassen. Dann würde ich das Intel Board nehmen. Läuft mit 12V. Habe da ein Netzteil mit Batterielader angeschlossen für den Fall das Netzspannung wegbricht. Unter diesem Link ist ein Alix Board bei mir zu Hause erreichbar. Im Bild auf der Seite ist das Intel Board eingebaut in ein Gehäuse. http://demo.klimaregelung.de?demo=inst_comp
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.