Lohnt es sich wirklich eine SDD Festplatte für Windows zu haben?

[Stefan 008]

ich dachte das stimmt eben nicht freier Speicher unter Windows = nicht freie Zellen auf der SSD da die SSD mit den Lösch kommandos von Win nix anfangen kann , Angenommen mein os is mit 16GB belegt , ich lade jetzt nochmal 16 GB aus dem inet runter , somit ist die SSD voll , nun lösche ich die vom internet 16GB geladenen Daten unter Windows wieder , somit hab ich in Windows wieder 16GB Frei , aber auf der SSD sind doch nun trotzdem 32GB belegt , also voll weil die SSD mit dem Lösch befehl nix anfangen kann , Was unter winxp als freier speicher angezeigt wird ist doch auf der SSD nicht wirklich in form von leeren / freien Zellen frei , ab jetzt muss dann erst das alte gelöscht werden um neues zu schreiben oder ?

Edit : und zu dem unpartitionierten oder Partitionierten oder wie auch immer Bereich , ich war der Meinung das Bringt nix weil der Controller der SSD bestimmt wo geschrieben wird und nich windows , somit kann ich zwar in windows eine PArtition haben die ich nie anrühre und nie Daten drauf speichere , das der SSD aber völlig egal ist , der Controller sieht aha da sind noch freie Zellen also schreibe ich erstmal da rein da ich die ja gleichmäßig verteilen muss , egal ob da was partitioniert is oder nich , Stimmt das jetzt oder nicht ? falls ja bringt die leere Partition ja nix oder auch der leere unpartitioniere Bereich .

Einzige lösung wäre die SSD Hersteller bringen ein Tool raus womit die Dateien die von Windows als gelöscht gelten sofort oder auch im nachhinein auf der SSD gelöscht werden können änlich einer Defragmentierung die man vielleicht einmal im Monat ausführt ,dabei müssten ja nur die dateien die in win gelöscht werden mit einer markierung versehen werden die der controller lesen kann , alle markierten werden dann auf der SSD gelöscht wenn gewünscht durch starten des Tools, somit wären dann wirklich die zellen wieder frei

 

[Warbeast]

Das ist genau richtig so.
Mann muss aber eben nicht erst die SSD voll beschrieben haben,das OS "überschreibt" halt auch Daten,darum kommt es schon früher dazu.

Der neue ATA TRIM Befehl teilt dem Controller in der SSD mit das er die vom BS gelöschten Daten auch tatsächlich löschen soll.

 

[Shagnar]

und welche vorraussetungen hat dieser trim befehl? nur windows 7 oder auch trim-fähige platte?

 

[-one]

und welche vorraussetungen hat dieser trim befehl? nur windows 7 oder auch trim-fähige platte?

http://www.heise.de/ct/Schnelle-Solid-State-Disks--/artikel/126494


Zitat:

Löscht das Betriebssystem Dateien oder verschiebt sie in den Papierkorb, so bekommt das Speichermedium davon nichts mit. Lediglich ein paar Bits im Dateinamen oder den Datenstrukturen des Dateisystems ändern sich und teilen dem Betriebssystem mit, dass der Platz anderweitig genutzt werden darf. So kann es passieren, dass der Flash-Controller mit viel Aufwand Daten umschichtet, die Anwender und Betriebssystem bereits als wertlos betrachten. Selbst eine frisch vom Betriebssystem formatierte „Platte“ ist aus Sicht des Flash-Controllers nahezu voll. Microsoft hat deshalb beim für die ATA-Spezifikation zuständigen Gremium einen Vorschlag für neue Befehle eingereicht. Mit dem Trim-Kommando teilt das Betriebssystem dem Laufwerk mit, welche Pages es nicht mehr braucht. Die Linux-Gemeinde arbeitet bereits vor Aufnahme der neuen Befehle in den Standard an einer Implementation.

 

[Fischhirn]

Hab jetzt einiges über die SSDs gelesen aber eine Frage wurde mir nicht richtig beantwortet:

Szenario: 32GB SSD wude komplett beschrieben, formatiert und ein OS drauf installiert.
Die SSD ist jetzt für den internen Controller ja immernoch voll. soweit hab ichs verstanden.

Aber wieso kann der Controller nicht einfach stur die zellen neu beschreiben, sondern muss sie erst auslesen und dann löschen und dann erst kann er schreiben?
HDDs können ja auch einfach über ein bestehendes magnetfeld, das aber für das OS als leer angesehen wird einfach neu drüberschreiben.

Liegt es daran, das man die Elektronen die beim vorigen Schreiben "eingefangen" sind erst durch einen löschprozess "rauslassen" muss? Aber wieso werden diese Daten erst in den Cache geladen (so hab ichs hier mal gelesen) ?

Verstehe also nicht wieso man das sowieso schon "gelöschte" nochmal in den Cache laden muss, um es dann wirklich zu löschen für einen neuen Schreibprozess oO

 

[Shagnar]

weil bei einer SSD nur eine gruppe mehrerer (vieler) zellen auf einmal angesprochen werden kann und nicht eine einzelne zelle allein
sprich: man muss einen "block" auf einmal (erase-block) löschen.. wenn da in dem block aber noch daten sind die man braucht müssen die davor umkopiert werden (sonst wären sie ja weg)

 

[Warbeast]

Wenn in dem ganzen Block wertlose Daten drinne sind fällt das cachen wohl weg,gelöscht muss der Block aber trotzdem werden,und das dauert eben.

 

[Stefan 008]

@Warbeast ok wenn das richtig ist wie ich es erklärt und angenommen habe abschliesend letzte Frage : Also bringt Druss01's Methode absolut nichts , oder hat es doch irgend ein Vorteil ?

Und Danke für die Aufklärung

 

[ayn]

kurz und knapp: kein vorteil, bringt nichts.

erklärung: nur die softwareschicht weis wie groß eine partition ist, nicht die hardwareschicht. in einen bestimmten bereich einer festplatte, der immer gleich ist, steht halt die partitionstabelle in der festgelegt wird wie der speicherplatz logisch aufgeteilt sein soll. das wird von der softwareschicht ausgelesen und anhanddessen werden die dateien dann katalogisiert.
der ssd-controler weis davon rein garnichts. der nimmt nur befehle entgegen. der controler der ssd kennt nur seinen maximal möglichen speicherbereich. das betriebssystem sagt nun den controler: schreibe 1 an adresse 0x000123. das tut der controler. das wear-levelling zählt nun einfach mit, wie oft eine flash-zelle schon beschrieben war und anstatt in block1 zu schreiben, schreibt das teil halt intern in block2 und adressiert den block1 um und gibt block2 die adresse von block1, rinse repeat. wenn alle blöcke belegt sind geht das eben nicht mehr und da hat man dann das problem mit den wear levelling. deswegen hat eine ssd auch immer reserveblöcke, die nicht zum gesamtspeicher dazugezählt werden, wo fleißig quasi der 100% speicherplatz immer hin und hergeschoben wird.
davon wiederrum weis das betriebsystem nichts, wie die ssd sich intern verteilt, denn die logische adressierung ist nicht statisch an die blöcke gebunden, die wechselt, dafür ist ebenfalls der ssd-controler verantwortlich.
irgendwann lagen dann durch das wear-levelling in jeder speicherzelle (die für das gesamtvolumen wichtig ist) mal daten. da der ssd-controler jedoch nicht weis, ob die daten noch wichtig sind, werden die immer brav hin- und hergeschaufelt, bis das betriebssystem sagt, dass das bit an adresse soundso geändert werden soll. der ssd-controler kennt also weder die dateien beim namen noch die partitionsgröße. für die ssd sind alle belegten blöcke gleich wichtig und nur das os, also die reine softwareschicht, sagt, was, wo, wann geändert werden soll. die partitionen sind dann nurnoch eine beschränkung für das betriebssystem, nicht für die ssd.

es bringt also nichts das ganze jetzt nur mit 80% zu partitionieren, da der ssd vollkommen unbekannt ist, wie groß die partition ist und irgendwann einfach alle blöcke mal angefasst wurden. das wird man in der tat ohne ata-trim nicht ändern können außer halt die ganze ssd komplett von allen altlasten zu befreien und von vorne anzufangen. (die erases, wie sie hier im forum beschrieben werden)

der einzige vorteil ist halt, dass man auf 80% partitionen auch nur 80% daten draufbekommt im verhältnis zum gesamtspeicherplatz und deswegen die möglichkeit besteht das es ein wenig länger dauert bis alle blöcke mal durch das wear levelling angefasst wurden. das wiederrum hängt aber auch stark von der art der nutzung ab.

für alles weitere müsst ihr euch mal mit dem osi sieben schichten modell abplagen, denn das gilt auch hierfür. (vorsicht, theoretische informatik...)

grüße

 

[sonix]

Aber die SDD weiss doch (bei einer 80% Partition) das nur 80% der verfügbaren Blöcke gemappt sind?
Wobei wahrscheinlich bei einem Write (z.B. 1 byte) auf eine Physikalische Adresse der SDD, einfach ein neuer Block angebraucht wird, was folglich immer zu einer Unverhältnismäßigkeit der gemappten Blöcke zum verbrauchten Speicherplatz führt und somit auch bei einer 80% Partition, 100% der Blöcke gemappt sind (irgendwann mal).

 

[KeinNameFrei]

Hab jetzt einiges über die SSDs gelesen aber eine Frage wurde mir nicht richtig beantwortet:

Szenario: 32GB SSD wude komplett beschrieben, formatiert und ein OS drauf installiert.
Die SSD ist jetzt für den internen Controller ja immernoch voll. soweit hab ichs verstanden.

Aber wieso kann der Controller nicht einfach stur die zellen neu beschreiben, sondern muss sie erst auslesen und dann löschen und dann erst kann er schreiben?
HDDs können ja auch einfach über ein bestehendes magnetfeld, das aber für das OS als leer angesehen wird einfach neu drüberschreiben.

Liegt es daran, das man die Elektronen die beim vorigen Schreiben "eingefangen" sind erst durch einen löschprozess "rauslassen" muss? Aber wieso werden diese Daten erst in den Cache geladen (so hab ichs hier mal gelesen) ?

Verstehe also nicht wieso man das sowieso schon "gelöschte" nochmal in den Cache laden muss, um es dann wirklich zu löschen für einen neuen Schreibprozess oO

Ja, es ist wirklich so, dass das direkte Überschreiben einer Flash-Zelle physikalisch unmöglich ist. Es muss zwangsläufig zuerst gelöscht werden.

Ist nun der ganze Block ungültig, dann muss der Controller eigentlich nicht Zwischenpuffern und Zurückschreiben, das ist auch richtig. Die Frage ist halt, ist so ein 08/15-Consumer-Controller tatsächlich schlau genug, das zu tun, oder wird einfach stur nach Schema F gearbeitet? Wir wissen es nicht.

Und selbst wenn ja - auch dann wäre nicht viel gewonnen. Ich habe hier auf der letzten mal die Zahl "25mal so lange wie eine einfache Schreiboperation" in den Raum gestellt, so über den Daumen gepeilt. Der Großteil des Extra-Zeitaufwandes kommt aber durch den Löschvorgang selbst zustande, denn der ist richtig aufwendig. Also selbst wenn sich der Controller das Zwischenpuffern und Zurückschreiben spart, würde es immer noch vielleicht 20x solange dauern.

(Anandtech hat für einen Samsung-SLC-Controller folgende Zeiten angegeben: Lesen 0,025 ms, Schreiben 0,05 ms, Löschen 2,0 ms.)

 

[Eggcake]

Der Löschvorgang ist aber bei SLC und MLC gleich aufwendig (laut Anand) - nur so als Bemerkung.

 

[Shagnar]

Wenn in dem ganzen Block wertlose Daten drinne sind fällt das cachen wohl weg,gelöscht muss der Block aber trotzdem werden,und das dauert eben.

bisher (also ohne TRIM) weiß der controller doch garnicht, ob daten gelöscht werden können (da im dateisystem schon lange als gelöscht betrachtet) oder eben nicht. wenn ich mich jetzt nicht irre.

Edit: ich seh grad, das wurde oben ja schon beantwortet.

 

[KeinNameFrei]

Doch, er weiß das, denn das Betriebssystem markiert sie ja als Ungültig. Allerdings nicht sofort - erst wenn er sich einen Block anschaut, in dem noch Platz sein müsste, stellt er fest, das Zelle X und Y hier mit ungültigen Daten belegt sind.

Er löscht sie nur nicht, weil Löschen so aufwendig ist, und ihm das Betriebssystem nicht sagen kann, in welchen Zellen das Zeug liegt!

 

[ayn]

Aber die SDD weiss doch (bei einer 80% Partition) das nur 80% der verfügbaren Blöcke gemappt sind?
Wobei wahrscheinlich bei einem Write (z.B. 1 byte) auf eine Physikalische Adresse der SDD, einfach ein neuer Block angebraucht wird, was folglich immer zu einer Unverhältnismäßigkeit der gemappten Blöcke zum verbrauchten Speicherplatz führt und somit auch bei einer 80% Partition, 100% der Blöcke gemappt sind (irgendwann mal).

nein, das weis die ssd eben nicht, wie groß die partition ist, woher auch?
die ssd verwaltet die partitionen nicht, das tut die softwareschicht, nicht die hardwareschicht.
die ssd weis, dass 30gb adressiert werden (das ist unsere basis, unsere 100%, die wir partitionieren können) und z.b. 100 reserveblöcke für das wear-levelling übrig bleiben zum umverteilen (davon weis das betriebsystem wiederrum nichts, die kann man nicht partitionieren, die sieht man nichteinmal).

wenn jetzt geschrieben wird und block1, der momentan adressiert ist, einmal mehr beschrieben wurde als reserveblock23, dann wird der inhalt von block1 ausgelesen, das vom os adressierte bit geändert und der neue inhalt in reserveblock23 geschrieben und dieser bekommt die adresse von block1, die wiederrum das os kennt, und block1 wird als reserveblock verwendet.

irgendwann sind alle blöcke durch das wear-levelling von unserer basis angefasst worden und dann ist essig, weil dann darf man erasen, wenn der ssd nicht genug reserveblöcke zur verfügung stehen.

und das hat mit 80% partitioniert oder nicht nichts zu tun. es gibt userspace und exklusiv reservierten "reservespace" und ob der user von seinen userspace nun 80% oder 100% benutzt interessiert die ssd nicht, sie weis es nicht, sie sieht es nicht, sie benutzt zum schreiben für sich selber das, was für sie frei ist und das ist der reservespace + die angewiesenen bits im userspace.

für die restliche verwaltung des "freien speichers" ist einzig und allein die softwareschicht zuständig, nicht die hardware.

ich weis, ist schwer zu verstehen aber deswegen ist informatik auch informatik

grüße

 

[Shagnar]

Doch, er weiß das, denn das Betriebssystem markiert sie ja als Ungültig. Allerdings nicht sofort - erst wenn er sich einen Block anschaut, in dem noch Platz sein müsste, stellt er fest, das Zelle X und Y hier mit ungültigen Daten belegt sind.

Er löscht sie nur nicht, weil Löschen so aufwendig ist, und ihm das Betriebssystem nicht sagen kann, in welchen Zellen das Zeug liegt!

ah, wieder was dazugelernt.

aber so gesehen ist das ja grober unfug, sie nicht zu löschen weil es so aufwendig ist... schließlich muss man es ja spätestens beim überschreiben tun (wie es im moment ohne TRIM ist) .. und zu diesem zeitpunkt hat man ja eh schon "viel arbeit"..

das erinnert mich gerade irgendwie an frühe dos-zeiten, die sache mit dem minutenlangen kopieren bevor festgestellt wird dass 100 byte zu wenig frei sind...

 

[Eggcake]

Das Problem ist, dass nur ganze Blöcke gelöscht werden können. Wenn jetzt von den 128 (whatever) Sektoren 5 gelöscht werden können und die SSD dies sofort macht (d.h. Block löschen, Daten (ohne die 5 Sektoren) neu schreiben), dann ist ein ganzer Schreibvorgang dahin --> Haltbarkeit nimmt so extrem schnell ab.

Macht er das für jeden stinkigen Sektor, ist die SSD wohl etwas sehr schnell im Eimer.
Darum wäre es wohl am sinnvollsten, ein "Defrag-Tool" zu entwickeln und jeden ~Monat alle Blöcke zu löschen und neu zu schreiben.

 

[KeinNameFrei]

Um genau zu sein sind es ja Löschzyklen, die die Lebensdauer von Flashzellen limitieren... es ist nur im allgemeinen mit Schreibzyklen gleichzusetzen, weil ja ab einem bestimmten Punkt (dem einmaligen Beschreiben aller Zellen) sowieso für jeden Schreibzyklus auch ein Löschzyklus erfolgen muss.

 

[Stefan 008]

@ayn Danke nochmal für die erklärung aber :

der einzige vorteil ist halt, dass man auf 80% partitionen auch nur 80% daten draufbekommt im verhältnis zum gesamtspeicherplatz und deswegen die möglichkeit besteht das es ein wenig länger dauert bis alle blöcke mal durch das wear levelling angefasst wurden. das wiederrum hängt aber auch stark von der art der nutzung ab.

für alles weitere müsst ihr euch mal mit dem osi sieben schichten modell abplagen, denn das gilt auch hierfür. (vorsicht, theoretische informatik...)

grüße

Das will mir nicht in den kopf , ich hab alles soweit verstanden und war mir auch vorher klar , aber wiederum schreibst du nun das die 80% doch einen vorteil haben und zwar das es dadurch länger duaert bis die zellen voll sind .

Wieso ? angenommen ich habe stets nur 1GB von der 32GB Mobi belegt rest ist alles Frei ( unter Windows ) dadurch das trotzdem innerhalb der 1GB daten mal verschoben , gelöscht , wieder aufgespielt usw... werden füllen sich die leeren zellen doch trotzdem , somit müsste es absolut völlig egal sein ob die platte voll , halb voll oder was auch immer is , durch verändern der daten werden leere zellen gefüllt , also kann mans durch nur 80% nutzung auch nicht rauszögern oder ?

 

[KeinNameFrei]

Manche Leute sind halt nicht so diszipliniert und knallen alles voll. Das ist alles.

 

[Stefan 008]

ob unter windows voll oder nicht ist doch egal , die zellen werden eh beschrieben

 

[Fischhirn]

Wieso ist es denn nicht möglich für SSDs andere formate zu benutzen? Sprich anstatt 512kB Blocks nur 1kB oder so, damitdas Cachen nicht so lange dauert bzw. man weniger oft Blöcke hat die nur zu 1% noch gebraucht werden und deswegen alles gespeichert werden muss bevor er gelöscht wird.

Wahrscheinlich oute ich mich jetzt als FAT, NTFS, etc- Noob aber frage mich wieso das keine Alternatie ist ^^ praktisch könnte man ja auf das Bit genau ansteuern, oder ist das durch den enorm großen Adressieraufwand nicht möglich?

 

[AristoChat]

^^ ExtremeFFS => google

 

[Fischhirn]

Jo das klingt schonmal gut was SanDsik da vor hat
Ich selbst werde noch bis Ende 09 warten bis die SSDs was sicherer sind ^^

 

[ronin24]

Hey,

also ich hab mich jetzt hier mal eingelesen und jetzt habe ich eine wichtige Frage und zwar, wenn z.B. Windows 7 den ATA TRIM Befehl drauf hat, brauch ich dann auch eine neue SSD mit neuem Controller oder reicht sagen war mal eine Mtron Mobi von heute ???

MFG Ronin

 

[Brotzeit]

Falls du noch Entscheidungsunterstüzung brauchst:

Klick mich

Hey,

also ich hab mich jetzt hier mal eingelesen und jetzt habe ich eine wichtige Frage und zwar, wenn z.B. Windows 7 den ATA TRIM Befehl drauf hat, brauch ich dann auch eine neue SSD mit neuem Controller oder reicht sagen war mal eine Mtron Mobi von heute ???

MFG Ronin

Du brauchst eine SSD die das Unterstüzt, die Indilinx tun es, die Mtron weiß ich nicht.

 

[WaDenKraMpF]

hier wird die ganze problematik mal durchgesprochen, zwar schon bissl älter der artikel aber finde ich anschaulicher als anantech...

Für ein SSD ist das sequentielle Schreiben eindeutig die bessere Wahl, da unnötige Löschvorgänge vermieden werden und die Performance darunter kaum leiden sollte. Sequentielles Schreiben lässt sich am besten dadurch erreichen, wenn der SSD-Kontroller ein sogenanntes "log structured file system" beherrschen würde. Kontroller, die Datenströme in sequentielle Vorgänge umwandeln und praktisch Random Writes überflüssig machen würden, existieren noch nicht auf dem Markt, sind aber in Entwicklung. Diese werden die Lebenszeit von SLC und MLC Solid State Drives drastisch erhöhen, ebenso ihre Schreibleistung. Ein kleiner Vorgeschmack hierzu gibt die Software „Managed Flash Technology (MFT)“ entwickelt von der Easy Computing Company.

Zu der Art der Nutzung gehört auch der Einsatz von Defragmentierungsprogrammen. Wird dieser durch ein eingebautes "log structured file system" in Zukunft ohnehin nebensächlich, ist das Defragmentieren schon durch die NAND‐Flash Technologie zu vernachlässigen.

need TRIM + "log structured file system" und die SSD rennen wie drecksau!

 

[Shagnar]

wenn ich das alles so durchlese bin ich grad froh dass ich nur eine billige 128GB transcend mit jmicronB controller gekauft habe.

die funktioniert soweit super (keine lags nach erfolgreicher einrichtung, super geschwindigkeit). ein jahr wird sie schon halten. danach gibts dann windows 7, TRIM, LSFS (log structured file system!) und es sind nochmal welten unterschiede

 

[KeinNameFrei]

Du brauchst eine SSD die das Unterstüzt, die Indilinx tun es, die Mtron weiß ich nicht.

Inilinx Barefoot und der neue Samsung Controller der zur Zeit eingeführt wird (z.B. OCZ Summit) beherrschen TRIM.

Intel nicht, Mtron nicht, JMicron-Controller sowieso nicht, alter Samsung-Controller nicht.

Macht ja auch Sinn - alle diese Produkte waren bereits auf dem Markt, als die Spezifikation im Oktober 08 abgesegnet wurde! Ich denke mal, sowohl Intel als auch Mtron werden in ihren nächsten Generationen garantiert auch TRIM unterstützen.

 

[ronin24]

Wird es leistungsmäßig grosse Unterschiede zwischen den derzeit erhältlichen SSDs (die TRIM unterstützen) und den neuen Mtrons, die dann TRIM unterstützen geben ???

Ja ich weiss dass das subjektiv ist, aber dann möchte ich eben eure subjektiven Meinungen hören.

MFG Ronin