Umstieg IDE auf SSD - Neuinstallation des BS notwendig?



  • Million Voices schrieb:

    Und noch einmal: Warum den virtuellen Arbeitsspeicher deaktivieren?

    Weil der die SSD tot schreibt und man den auf modernen Rechnern, die sowieso üppig RAM haben, sowieso nicht mehr benötigt.



  • Trim einschalten schrieb:

    Weil der die SSD tot schreibt

    lol



  • hustbaer schrieb:

    Trim einschalten schrieb:

    Weil der die SSD tot schreibt

    lol

    Moderner Flashspeicher der in 19 nm gefertigt wird verkraftet kaum noch 1000 Schreibzyklen.
    Das muss alles durch größere Datenträger bei denen man dann noch möglichst nicht den ganzen Platz belegt kompensiert werden.
    Und gerade die Cacherei, die zu sehr vielen Schreibzugriffen führt ist gift.



  • Trim einschalten schrieb:

    hustbaer schrieb:

    Trim einschalten schrieb:

    Weil der die SSD tot schreibt

    lol

    Moderner Flashspeicher der in 19 nm gefertigt wird verkraftet kaum noch 1000 Schreibzyklen.
    Das muss alles durch größere Datenträger bei denen man dann noch möglichst nicht den ganzen Platz belegt kompensiert werden.

    Ok, mach ich. Zur Zeit 44% belegt.

    Trim einschalten schrieb:

    Und gerade die Cacherei, die zu sehr vielen Schreibzugriffen führt ist gift.

    Ist mir egal, nach 5 Jahren dürfen sie ruhig ausfallen. Ich quäle Flashspeicher schonungslos, wenn sichs irgendwie anbietet. Muss doch einen Grund haben, irgendwann auf noch moderneren schnelleren umsteigen zu dürfen. Die Biester halten eigentlich noch viel zu lange.

    Auslagerungsdatei ist aber bei mir auch aus, weils den Abkacker durch Speicherloch nur eine Woche weiter verzögert, in der der Rechner dann sogar lahm ist.



  • hustbaer schrieb:

    Trim einschalten schrieb:

    Weil der die SSD tot schreibt

    lol

    Das ist nur logisch. Ich hatte mal längere Zeit einen Rechner mit unterdimensioniertem RAM. Resultat war, dass die Festplatte nach 2,5 Jahren ausfiel. Das wäre mir sicherlich erspart geblieben, wenn ich mehr RAM gehabt hätte. Ich denke, gerade bei SSDs sollte man darauf achten genügend RAM zu haben und das OS so einzustellen, dass bei einem Schlafenlegen alles im RAM behalten wird anstatt dass die SSD beschrieben wird.
    Festplattenausfälle sind einfach Scheiße. Backups hin oder her.

    L. G.,
    IBV



  • Trim einschalten schrieb:

    hustbaer schrieb:

    Trim einschalten schrieb:

    Weil der die SSD tot schreibt

    lol

    Moderner Flashspeicher der in 19 nm gefertigt wird verkraftet kaum noch 1000 Schreibzyklen.

    Ist mir bekannt.

    Das muss alles durch größere Datenträger bei denen man dann noch möglichst nicht den ganzen Platz belegt kompensiert werden.

    Wie viel Platz man belegt hat ist dank Wear-Leveling mehr oder weniger egal. Natürlich sollte man bei SSDs die wenig oder gar kein Over-Provisioning haben nicht alles anfüllen. Das heisst aber nicht dass man sich z.B. ein 120 GB Laufwerk kaufen muss und dann nur 60 GB anfüllen darf.

    Und gerade die Cacherei, die zu sehr vielen Schreibzugriffen führt ist gift.

    Welche Cacherei? Sorry, verstehe ich nicht.

    Die Sache ist mMn. relativ einfach: wenn man so wenig Speicher hat, dass man merkt dass es durch Paging langsamer wird, dann sollte man mehr Speicher reinstecken.
    Wenn man genug Speicher hat, so dass man auch trotz deaktiviertem Pagefile nie eine "es wird jetzt knapp" Meldung vom OS bekommt, dann kann man es natürlich deaktiviert lassen.

    Wenn man allerdings in dem Bereich dazwischen ist, wo es nie wirklich schlimm langsam wird, aber man bei deaktiviertem Paging doch noch hin und wieder ne Meldung vom OS bekommen würde, dann lässt man es einfach an. Weil es lange nich so schlimm für die SSD ist wie oft gerne behauptet wird. Natürlich kann man sich statt dessen auch mehr RAM kaufen - ist sicher auch keiner Fehler.
    Das Pagefile abzudrehen, und dann immer Programme schliessen zu müssen wenn's mal wieder knapp wird, ist mMn. aber ziemlich sinnfrei.



  • hustbaer schrieb:

    Und gerade die Cacherei, die zu sehr vielen Schreibzugriffen führt ist gift.

    Welche Cacherei? Sorry, verstehe ich nicht.

    Kann sich nur um http://en.wikipedia.org/wiki/Smart_Response_Technology oder besser http://www.dragonflybsd.org/performance/ handeln.



  • Wenn da die SSD nicht total unterdimensioniert ist, sollte das auch kein Problem sein. Weil dabei auch nicht dauernd umkopiert wird. Wäre ja sinnfrei - wenn der Cache dauernd umkopieren müsste wäre er wohl kaum sehr effektiv.

    Ich sehe also auch hier kein grosses Problem.



  • hustbaer schrieb:

    Das muss alles durch größere Datenträger bei denen man dann noch möglichst nicht den ganzen Platz belegt kompensiert werden.

    Wie viel Platz man belegt hat ist dank Wear-Leveling mehr oder weniger egal.

    Nein, denn damit Wear Leveling funktioniert, braucht es Blöcke in denen noch leere Pages vorhanden sind.

    Sind aber alle Pages eines Blocks vollgeschrieben, dann rührt Wear Leveling diesen Block nicht an, denn das würde ja nichts bringen, einen vollbeschriebenen Block zu löschen und dann wieder voll zu schreiben.

    Es werden also nur Blöcke für Wear Leveling verwendet, in der sich noch leere Pages befinden.

    Schreibt man aber alles voll, dann sind auch alle Pages dicht und es gibt immer weniger freie Blöcke mit leeren Pages.
    Wenn das erreicht ist, schreibt die SSD auf dem für Wear Leveling reservierten Bereich herum. Das sind ca. 5 % der Gesamtkapazität, die dem Nutzer auch so direkt nicht zur Verfügung steht.
    Und dieser Platz geht dann halt letzten endes irgendwann durch die Cacherei kaputt.

    Bei einer 1 TB großen Platte, mit 19 nm RAM sind das also ca. 50 GB die etwa 1000 mal vollgeschrieben werden können, ehe diese große SSD ausfällt.
    Der Rechner müßte also 50 TB beschreiben, bei großen Platten geht das also vielleicht noch.

    Aber bei kleinen Platten, z.b. 128 MB mit dem gleichen modernen Flashspeicher in 19 nm Fertigung sieht's aber schlechter aus, da sind es nur 6,4 GB die 1000 mal beschrieben werden können.
    Das sind nur 6,5 TB, die kann man durchaus nach einiger Zeit erreichen.

    Und gerade die Cacherei, die zu sehr vielen Schreibzugriffen führt ist gift.

    Welche Cacherei? Sorry, verstehe ich nicht.

    Ich meine die Auslagerungsdatei.

    Die Sache ist mMn. relativ einfach: wenn man so wenig Speicher hat, dass man merkt dass es durch Paging langsamer wird, dann sollte man mehr Speicher reinstecken.
    Wenn man genug Speicher hat, so dass man auch trotz deaktiviertem Pagefile nie eine "es wird jetzt knapp" Meldung vom OS bekommt, dann kann man es natürlich deaktiviert lassen.

    Ich sagte ja, auf modernen Rechnern braucht man das nicht mehr.

    Das Pagefile abzudrehen, und dann immer Programme schliessen zu müssen wenn's mal wieder knapp wird, ist mMn. aber ziemlich sinnfrei.

    Nein, das sehe ich nicht so.
    Denn wenn der Rechner auslagern muss, dann merkt man das bei SSDs nicht negativ, wie bei HDs.
    Die Latenz liegt bei Flashspeicher bei ca. 120 ns, das ist sau schnell.
    Der Nutzer gerät daher in Versuchung, das RAM ewig klein zu lassen, weil er das Paging das zweifelsohne bei wenig RAM stattfindet, gar nicht mehr negativ bemerkt.

    Bei Festplatten war das anders, da war das Paging so nervend, dass der Nutzer freiwillig mehr RAM kaufen ging.
    Dafür konnten HDs beliebig oft beschrieben werden, was bei SSDs eben nicht geht.



  • @Trim einschalten
    Du hast offensichtlich Wear-Leveling bzw. allgemein wie SSDs arbeiten nicht verstanden.

    Eine SSD teilt den Speicher nicht in "normal" und "für Wear-Leveling reserviert" ein, und verwendet dann nur die 5% (die übrigens in Wirklichkeit 7% sind) für Wear-Leveling wenn man die SSD vollschreibt.
    Es wird immer der gesamte Speicher verwendet, weil es eine solche Unterteilung eben nicht gibt.
    Das einzige was nötig ist, ist, dass eben immer ein bestimmter Prozentsatz an Speicher frei ist, damit die SSD "umorganisieren" kann. Und dafür wird bei den meisten SSDs mit Over-Provisioning gesorgt.

    Dabei (Wear-Leveling) werden auch z.b. Daten von Files die nur 1x geschrieben wurden, und danach nie mehr geändert, umgelagert, damit die Flash-Blöcke gleichmässig abgenutzt werden.

    Nicht umsonst geben viele Hersteller an dass man auf ihre 120 GB SSDs > 50 TB Daten draufschreiben kann (bei einigen Modellen sogar jenseits der 400 TB). Und das sind auch nicht bloss leere Angaben, es gibt durchaus Leute die das verifizieren. Und das Ergebnis: die Herstellerangaben sind sogar sehr konvervativ, in Wirklichkeit halten die Dinger viel mehr aus.

    http://techreport.com/review/26058/the-ssd-endurance-experiment-data-retention-after-600tb
    http://ssdendurancetest.com/
    Zitat aus dem Techreport Artikel

    techreport schrieb:

    By far the most telling takeaway thus far is the fact that all the drives have endured 600TB of writes without dying. That's an awful lot of data—well over 300GB per day for five years—and far more than typical PC users are ever likely to write to their drives. Even the most demanding power users would have a hard time pushing the endurance limits of these SSDs.



  • Nutzt man denn die Performance einer SSD überhaupt aus, wenn sie am SATA-Port hängt? Eigentlich ist das doch lächerlich, da sie doch immer noch unterfordert ist. Am PCIexpress-Port holt sie theoretisch zehn mal mehr Geschwindigkeit raus.

    Hat jemand schon mal Praxis-Erfahrung und kann Vergleichswerte liefern?



  • Also lächerlich ist das ganz und gar nicht. Die Hersteller mussten schon einiges tun damit ihre SSDs Geschwindigkeiten von 100.000 IOPS bzw. 500 MB/s schaffen. 10x schneller schafft im Moment keine einzige SSD.

    Und wenn es so lächerlich ist, was soll dann bitte die Alternative sein? Doch bei HDD bleiben? lol



  • Wie gesagt, nicht die SSDs sind lächerlich, sondern der Port an dem sie heute angeschlossen werden (SATA). Am PCIe sollen sie ja noch schneller sein.



  • Die 100.000 IOPS und 500 MB/s schaffen die SSDs an nem SATA Port.
    Weiss nicht was daran lächerlich sein soll.



  • hustbaer schrieb:

    Die 100.000 IOPS und 500 MB/s schaffen die SSDs an nem SATA Port.
    Weiss nicht was daran lächerlich sein soll.

    Zumal ausgerechnet jetzt, wo kein Rechner mehr unter 8G hat und man nur 2-3 G braucht (so für browsen und compilieren und genug Plattencache für alle Projekte und Anwendungen, die man so die Woche über anfasst), die Plattengeschwindigkeit irrelevant geworden ist.



  • Naja, manchmal muss man seinen Rechner auch rebooten. Da finde ich es dann schon gut dass nicht alles erstmal ewig dauert, bis die wichtigsten Sachen wieder im Cache stehen.
    Die 8 GB die mein PC in der Arbeit hat werden auch schon hin und wieder knapp.
    Und wenns ans Bauen von grossen Projekten geht, bin ich auch sehr froh dass ich ne schnelle SSD habe.

    Ich würde auf jeden Fall nicht zurück zu HDDs wollen, ganz egal wie viel RAM der PC hat und was ich damit mache.



  • hustbaer schrieb:

    @Trim einschalten
    Du hast offensichtlich Wear-Leveling bzw. allgemein wie SSDs arbeiten nicht verstanden.

    Eine SSD teilt den Speicher nicht in "normal" und "für Wear-Leveling reserviert" ein, und verwendet dann nur die 5% (die übrigens in Wirklichkeit 7% sind) für Wear-Leveling wenn man die SSD vollschreibt.
    Es wird immer der gesamte Speicher verwendet, weil es eine solche Unterteilung eben nicht gibt.

    Du hast gar nicht verstanden was ich geschrieben habe.

    Es gibt diesen extra Platz, ich habe aber nicht gesagt, dass nur dieser extra Platz genutzt wird, sondern ich sagte, wenn alle Pages aller normal verfügbaren Blöcke vollgeschrieben sind nur noch dieser Restplatz übrig bleibt und so funktioniert Wear Leveling.

    Wear Leveling rührt nämlich keine Blöcke an in der alle Pages bereits vollgeschrieben sind, das ergibt nämlich keinen Sinn, die gleiche Datenmenge zu löschen und dann wieder zu beschreiben.
    Es werden also nur Blöcke angerührt, in der auch leere Pages vorhanden sind.

    Dabei (Wear-Leveling) werden auch z.b. Daten von Files die nur 1x geschrieben wurden, und danach nie mehr geändert, umgelagert, damit die Flash-Blöcke gleichmässig abgenutzt werden.

    Eine SSD arbeitet und denkt aber nicht in Files, sondern in Blöcke.
    Wenn der Block randvoll ist, also alle Pages vollgeschrieben sind, dann wird dieser Block nicht angerührt, auch dann nicht, wenn er nur einmal benutzt wurde.

    Das kannst du dir ganz einfach erklären, denn was würde denn passieren, wenn dieser Block umgeschichtet werden würde? Es würde natürlich ein anderer Block mit den Daten vollgeschrieben werden, aber da die Daten so fett sind, das sie gleich einen ganzen Block füllen, hätte die Umschichterrei gar nichts gebracht, außer eben unnötige Schreibzyklen zu verheizen.



  • Artchi schrieb:

    Wie gesagt, nicht die SSDs sind lächerlich, sondern der Port an dem sie heute angeschlossen werden (SATA). Am PCIe sollen sie ja noch schneller sein.

    SATA wurde für HDs und optische Datenträger entwickelt, damit bringt es für SSDs einen unnötigen Protokolloverhead mit, den SSDs emulieren müssen, damit sie in einer SATA Umgebung wie gewünscht funktionieren.

    Es wird nicht mehr lange dauern, und SATA wird von neuen Standards für SSDs abgelöst, die dann direkt an den PCIx Bus angebunden werden.
    http://www.golem.de/news/pcie-ssd-sata-express-und-ngff-sind-das-ende-von-sata-1209-94578.html

    Vorraussichtlich wird man die ersten MB mit diesen neuen Standards ab dem Broadwell Nachfolger kaufen können.



  • Trim einschalten schrieb:

    Du hast gar nicht verstanden was ich geschrieben habe.

    (...)

    Wear Leveling rührt nämlich keine Blöcke an in der alle Pages bereits vollgeschrieben sind, das ergibt nämlich keinen Sinn, die gleiche Datenmenge zu löschen und dann wieder zu beschreiben.
    Es werden also nur Blöcke angerührt, in der auch leere Pages vorhanden sind.

    Nein, du hast nichts verstanden.

    Natürlich werden Blöcke "angerührt" wo alle Pages belegt sind, denn natürlich macht es Sinn.
    Man liest sie an einer Stelle, und schreibt sie dann wo anders hin.
    Der Sinn davon ist Blöcke frei zu machen die noch nicht oft geschrieben wurden.

    Hast du dir das selbst zusammengereimt oder wo hast du diesen Unsinn her?

    Das kannst du dir ganz einfach erklären, denn was würde denn passieren, wenn dieser Block umgeschichtet werden würde? Es würde natürlich ein anderer Block mit den Daten vollgeschrieben werden, aber da die Daten so fett sind, das sie gleich einen ganzen Block füllen, hätte die Umschichterrei gar nichts gebracht, außer eben unnötige Schreibzyklen zu verheizen.

    Schon wieder dieser Unsinn. Mach dich bitte ein wenig Schlau bevor du hier Unsinn verzapfst, obwohl es dir schon korrekt gesagt wurde.
    http://en.wikipedia.org/wiki/Wear_leveling#Static_wear_leveling



  • hustbaer schrieb:

    Die Sache ist mMn. relativ einfach: wenn man so wenig Speicher hat, dass man merkt dass es durch Paging langsamer wird, dann sollte man mehr Speicher reinstecken.
    Wenn man genug Speicher hat, so dass man auch trotz deaktiviertem Pagefile nie eine "es wird jetzt knapp" Meldung vom OS bekommt, dann kann man es natürlich deaktiviert lassen.

    Wenn man allerdings in dem Bereich dazwischen ist, wo es nie wirklich schlimm langsam wird, aber man bei deaktiviertem Paging doch noch hin und wieder ne Meldung vom OS bekommen würde, dann lässt man es einfach an. Weil es lange nich so schlimm für die SSD ist wie oft gerne behauptet wird. Natürlich kann man sich statt dessen auch mehr RAM kaufen - ist sicher auch keiner Fehler.
    Das Pagefile abzudrehen, und dann immer Programme schliessen zu müssen wenn's mal wieder knapp wird, ist mMn. aber ziemlich sinnfrei.

    Mehr RAM ist gerade in Notebooks nicht immer eine Option. Ansonsten verweise ich hier mal auf Russinovich:

    So how do you know how much commit charge your workloads require? You might have noticed in the screenshots that Windows tracks that number and Process Explorer shows it: Peak Commit Charge. To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number.

    Some feel having no paging file results in better performance, but in general, having a paging file means Windows can write pages on the modified list (which represent pages that aren’t being accessed actively but have not been saved to disk) out to the paging file, thus making that memory available for more useful purposes (processes or file cache). So while there may be some workloads that perform better with no paging file, in general having one will mean more usable memory being available to the system (never mind that Windows won’t be able to write kernel crash dumps without a paging file sized large enough to hold them).

    Quelle: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx


Anmelden zum Antworten