Die X25-M wäre die EINZIGE MLC, die ich mal probieren würde!
Auf <64GB patitioniert und dann mal laufen lassen.
Ansonsten aber nur SLC - für mich.
Lohnt es sich wirklich eine SDD Festplatte für Windows zu haben?
- Ersteller D_D
- Erstellt am
Die X25-M wäre die EINZIGE MLC, die ich mal probieren würde!
Auf <64GB patitioniert und dann mal laufen lassen.
Ansonsten aber nur SLC - für mich.
seppelchen
Foto-Master of 03/11
Sehe ich ähnlich
Was ich halt nicht verstehe ist folgendes... Wieso sich eine SSD oder 2 im RAID kaufen und wegen der horrenden Preise könnens nur 32GB sein (meinetwegen 64GB, aber 600!! Euro dafür ausgeben?). Wozu das Windows und ein paar Programme darauf installieren, wenn bei den Anwendungen wo es drauf ankommt (Videoschnitt / codieren) wegen Platzmangel mit einer normalen HDD hantiert werden muss. Ich wollte mir auch ein oder 2 kaufen, aber genau aus diesem Punkt habe ich es sein lassen. Der schnelle Systemstart ist eine feine Sache, aber wie oft starte ich den PC am Tag? Schnelles öffnen der Programme, wenn die einmal im Speicher sind, gehts auch schnell. Ich kaufe mir erst diese Dinger, wenn die mit ausreichend Kapazität und vorallem zu bezahlbaren Preisen erhältlich sind. Das wird vmtl. mit dem Start von Windows 7 in etwa zusammenfallen und dann dürfen die in den PC.
Vielleicht liegts einfach daran, dass ich anstatt der 55 IOPS meiner Samsung HD 10'000 bis 20'000 IOPS hab? :>
Türlich ists teuer. Aber ich wüsste jetzt nicht welches Programm auf einer 64GB SSD kein Platz finden würde.
Naja in der Praxis vielleicht nicht ganz so viele IOPS, aber verglichen mit 30-50 ...
Türlich ists teuer. Aber ich wüsste jetzt nicht welches Programm auf einer 64GB SSD kein Platz finden würde.
Naja in der Praxis vielleicht nicht ganz so viele IOPS, aber verglichen mit 30-50 ...
Zuletzt bearbeitet:
Die HDD war das Einzige, was ich von meinem PC noch gehört habe, insofern...Sehe ich ähnlich
Was ich halt nicht verstehe ist folgendes... Wieso sich eine SSD oder 2 im RAID kaufen und wegen der horrenden Preise könnens nur 32GB sein (meinetwegen 64GB, aber 600!! Euro dafür ausgeben?). Wozu das Windows und ein paar Programme darauf installieren, wenn bei den Anwendungen wo es drauf ankommt (Videoschnitt / codieren) wegen Platzmangel mit einer normalen HDD hantiert werden muss. Ich wollte mir auch ein oder 2 kaufen, aber genau aus diesem Punkt habe ich es sein lassen. Der schnelle Systemstart ist eine feine Sache, aber wie oft starte ich den PC am Tag? Schnelles öffnen der Programme, wenn die einmal im Speicher sind, gehts auch schnell. Ich kaufe mir erst diese Dinger, wenn die mit ausreichend Kapazität und vorallem zu bezahlbaren Preisen erhältlich sind. Das wird vmtl. mit dem Start von Windows 7 in etwa zusammenfallen und dann dürfen die in den PC.
Da ich Fallout3 durch habe und erst einmal genug zu tun, wird mir die nächste Zeit die eine 32GB-SSD reichen, danach kommt noch eine für Spiele.
Mehr mache ich mit dem Rechner nicht.
Edit: schöne Fotos, Seppelchen!
seppelchen
Foto-Master of 03/11
Thx 
Wie gesagt, scharf wäre ich schon drauf, aber die Dinger kosten einfach zuviel pro GB
Aber hey, ich gönn euch den Spaß
Wie gesagt, scharf wäre ich schon drauf, aber die Dinger kosten einfach zuviel pro GB
Aber hey, ich gönn euch den Spaß
Da zitier ich nur
Gruß
kosten ist relativ. mit keiner meiner aufrüstungsunternehmungen (außer mit den sprung vom pentium75 auf ein celeron 333A mit überlackierten pin b21 ) hab ich soviel leistungssteigerung pro euro bekommen.
verglichen mit magnetplattenspeicher ist eine ssd natürlich teuer, verglichen mit dem leistungsgewinn sind die "paar euros" jeden cent wert.
grüße
) hab ich soviel leistungssteigerung pro euro bekommen.verglichen mit magnetplattenspeicher ist eine ssd natürlich teuer, verglichen mit dem leistungsgewinn sind die "paar euros" jeden cent wert.
grüße
AristoChat
Semiprofi
- Mitglied seit
- 05.08.2004
- Beiträge
- 1.764
IOPS HDD hat gar nix mit IOPS SSD zu tun ... es gibt keinen Zusammenhang zwischen beiden
KeinNameFrei
Enthusiast
ATA TRIM (nur ein M!) ist eine der im Oktober 2008 beschlossenen Erweiterungen des ATA-Interface-Standards für Festplatten und -Controller, welche sich vor allem an SSDs richtet und die Kommandos zum Löschen von Daten ersetzt.
Im Moment ist es so, dass das Betriebssystem die SSD nicht zum Löschen einer Zelle anweisen kann, da die Verwaltung der eigentlichen Zellen beim SSD-Controller liegt, und das OS nur weiß, wieviel Platz zur Verfügung steht. Daher wird eine Zelle, die gelöschte Daten enthält, solange ignoriert, bis der Controller in diese Zelle etwas anderes hineinschreiben möchte. Ist ja kein Problem, die alten Daten sind ja ungültig.
Das Problem ist aber 1) dass man Flash-Speicher bauartbedingt nicht überschreiben, sondern nur löschen kann, und 2) dass man nur Sammelblöcke aus sehr vielen Zellen, und nicht einzelne Zellen löschen kann. Der Controller muss also die noch gültigen Daten aus den anderen Zellen im Block auslesen, den kompletten Block blankputzen, und dann die Daten wieder zurückschreiben. Und erst dann kann die Schreiboperation ausgeführt werden, auf die du als Benutzer gerade wartest. Wenn ich dir jetzt sage, dass das Löschen und Neubefüllen eines Blockes ca. 25mal so lange dauert, wie die eigentliche Schreiboperation, siehst du sicher das Problem
Mit dem TRIM-Kommando kann in Zukunft ein Betriebssystem der SSD nicht nur sagen: "ich habe Datei A gelöscht", sondern auch: "mach mal alle Zellen platt, in denen sie drin war" (vom Englischen 'to trim' = 'wegschneiden'). Jetzt wird also der ganze Vorgang mit Block auslesen > Block blankputzen > Block zurückschreiben schon an der Stelle durchgeführt, an dem du als Benutzer auf Löschen gedrückt hast. Und da du zu der Zeit nichts anderes machst, als eben auf Löschen zu drücken, läuft der Vorgang 'im Hintergrund' ab, ohne dass es irgend einen anderen Vorgang verlangsamen könnte.
Wenn du dann einen Schreibvorgang auslöst, der die Zellen benötigt, in denen vorher Datei A drin war, dann sind sie schon frei und der Schreibvorgang kann sofort durchgeführt werden.
Master Luke
Enthusiast
warum nicht?
DaReal
Enthusiast
Bei dem ganzen HIN und HER auf dem SSD Markt habe ich mich jetzt doch erstmal noch für ne Velo entschieden, wenn sich das alles langsam beruhigt, zuverlässige Controller draußen sind und auch die Preise etwas sinken werde ich miteinsteigen.
Derzeit gibts wohl wirklich nur eine Serie wirklich zuverlässiger und robuster Laufwerke (Mtron) und diese haben halt noch einen recht hohen Preis, da verzichte ich auf 2 Sekunden schnellere Bootzeiten.
Derzeit gibts wohl wirklich nur eine Serie wirklich zuverlässiger und robuster Laufwerke (Mtron) und diese haben halt noch einen recht hohen Preis, da verzichte ich auf 2 Sekunden schnellere Bootzeiten.
AristoChat
Semiprofi
- Mitglied seit
- 05.08.2004
- Beiträge
- 1.764
Ist das gleiche wie wenn du ein Auto mit einem Pferd vergleichst.
Vergleich ist legitim aber ergibt keinen Sinn.
Das Problem ist halt dass eine SSD 300x oder 500x bessere IOPS Random Performance haben kann aber die Evolution in diesem Gebiet bei HDD's schon lange abgebrochen ist.
Und eine "neue" 20k RPM HDD wird auch nichts bahnbrechendes bringen ...
Im grossen ganzen heisst es das neue "Metrics" definiert werden müssen um die Performance bei SSDs zu messen und dann von den Hersteller/User als Standard benutzt werden.
Zuletzt bearbeitet:
Master Luke
Enthusiast
danke für deine antwort.
ich hatte jetzt eine antwort erhofft, die sich z.B. explizit auf ein Tool wie hdtune 3.5 bezieht.
ein dortiger vergleich, unabh. der laufwerkstechnologien, bringt unter der gleichen software unterschiedliche ergebnisse.
ich dachte immer, "IOPS" setzen sich zusammen aus transferrate und zugriffsszeit - ist denn dann der mechanismus der laufwerke nicht egal und die ergebisse somit vergleichbar?
ok, du hast geschrieben "Vergleich ist legitim aber ergibt keinen Sinn."... aber ichsehe solche IOPS-tools als indikator. inwiefern das RL entspricht... tjo...
danke & gruß
Zuletzt bearbeitet:
perfekte erklärung, vielen dank dafür.
die tatsache dass das zweite m zuviel ist, war auch der grund wieso google nichts ausgespuckt hat
- Mitglied seit
- 02.08.2003
- Beiträge
- 2.317
@Druss01
was passiert wenn man der Mobi einen unpartitionierten Bereich übrig lässt ? das ist ja dann ein Bereich der gar nicht genutzt wird ( nicht von Windows und auch nicht von der SSD ) somit läuft der Partitionierte Bereich ja
trotzdem voll oder wird der unpartitionierte Bereich von der Mobi aber nicht von Windows genutzt ? dann würde sie ja aber auch früher oder später voll laufen ,oder habe ich nen Denkfehler ?
Habe auch 2 Mobis und bin damit super zufrieden , eine HDD fürs System möcht ich nimmer haben aber das mit dem unpartitionierten Bereich würde mich jetzt schon interessieren , bitte um Aufklärung dann mach ich das mit meinen Mobis auch
Danke
was passiert wenn man der Mobi einen unpartitionierten Bereich übrig lässt ? das ist ja dann ein Bereich der gar nicht genutzt wird ( nicht von Windows und auch nicht von der SSD ) somit läuft der Partitionierte Bereich ja
trotzdem voll oder wird der unpartitionierte Bereich von der Mobi aber nicht von Windows genutzt ? dann würde sie ja aber auch früher oder später voll laufen ,oder habe ich nen Denkfehler ?
Habe auch 2 Mobis und bin damit super zufrieden , eine HDD fürs System möcht ich nimmer haben
aber das mit dem unpartitionierten Bereich würde mich jetzt schon interessieren , bitte um Aufklärung dann mach ich das mit meinen Mobis auch Danke
WaDenKraMpF
Neuling
auch wenn du einen Bereich nicht partitionierst, werden die Zellen dort trotzdem von der SSD benutzt!
Der Bereich hilft dir bei ner Intel X25M den 80% performanceeinbruch zu verhindern...
glaube den allermeisten anderen hilft er nicht wirklich viel. Zwar wird jede SSD mit Write Combine langsamer je voller sie wird, aber linear und nicht wie bei der intel ziemlich aprupt bei 80%...
Der Bereich hilft dir bei ner Intel X25M den 80% performanceeinbruch zu verhindern...
glaube den allermeisten anderen hilft er nicht wirklich viel. Zwar wird jede SSD mit Write Combine langsamer je voller sie wird, aber linear und nicht wie bei der intel ziemlich aprupt bei 80%...
- Mitglied seit
- 02.08.2003
- Beiträge
- 2.317
ok wenn es nur die Intel betrifft wieso macht Druss01 das bei seiner Mobi ? , das meinte ich ja das die zellen trotzdem benutzt werden also was bringt das bezüglich des Alterns ?
das ganze Problem der MLCs betrifft doch die SLC (sprich MTRON oder Intel E) garnicht, daher ist eine Partitionierung zur Verhinderung des 80 %-Füllens unnötig, und die Lebensdauer einer SLCs ist ohnehin 10mal länger als bei einer MLC. also dont worry!
- Mitglied seit
- 02.08.2003
- Beiträge
- 2.317
Druss01 schrieb
@schweiger
yup dachte ich auch , deswegen warte ich noch auf ein Statement von Druss01 da seine Mobi ja genau wie meine beiden eine SLC ist und keine MLC
@schweiger
yup dachte ich auch , deswegen warte ich noch auf ein Statement von Druss01 da seine Mobi ja genau wie meine beiden eine SLC ist und keine MLC
Zuletzt bearbeitet:
Lest doch einfach nur mal den Artikel von AnandTech, der den grundsätzlichen Aufbau ALLER SSDs erklärt.
Vollkommen egal, ob MLC oder SLC bzw. ob 1 Bit oder 2 Bit pro Zelle gespeichert werden, die SSD löscht ja zunächst einmal nichts, sondern schreibt erst einmal dort weiter, wo noch nichts geschrieben wurde.
Irgendwann kommt ja dann der Punkt, an dem bei meiner 32GB SSD (um mal ein Beispiel zu haben) der gesamte Platz schon einmal beschrieben wurde und die SSD somit mal voll ist, auch wenn im System vielleicht nur 10GB auftauchen. In Wirklichkeit wurde aber jede Zelle/jeder Baustein der SSD schon einmal beschrieben, bei den SSDs besteht ja im Gegensatz zu den HDDs nicht die Möglichkeit, Sektoren zu löschen.
Bei der SSD muss der elektrisch generierte Zustand der Zelle zurückgesetzt werden, bzw. die Zelle muss frei gemacht werden. Nun gibt es das nächste bauartbedingte Problem: einzelne Zellen können nicht gelöscht werden, sondern immer nur Blocks von 512kb.
Wenn die SSD also bei einer "vollen" Bestückung neues schreiben will, muss sie selbst für einen kleinen Speicherplatz von 4kb, der vielleicht noch vom letzten zu speichernden Volume der letzten freien Page oder Blocks übrig ist, einen 512kb großen Block löschen. Also muss dann erst einmal in den Cache gelegt werden, der Block wird gelöscht und dann wird aus dem Cache in den nun freien Block geschrieben.
Der Zustand der prinzipiell voll belegten SSD wird als "Low Level State" bezeichnet, weil dem User eine Geschwindigkeitsabnahme auffällt, die auf den oben beschriebenen und nun notwendigen Vorgang des Cache-löschen-schreiben zurückzuführen ist.
Wenn man nun einen Bereich partitioniert und einen (unpartitionierten oder partitionierten) Bereich frei lässt, dann kann die SSD für kleine, z.B. 4kb große zu schreibende Daten diesen Bereich auffüllen und braucht keinen Blcok zu löschen.
Im Prinzip ist das eine vereinfachte Defragmentierung, bei der die 512kb großen Blöcke mit 4kb großen Daten aufgefüllt werden können (natürlich vereinfacht ausgedrückt, wenn wie im Beispiel die überhängenden Daten immer nur 4kb groß wären).
Wie gesagt, dies betrifft auch die SLC-SSDs, weil diese bis auf die einzelne Zelle gleich aufgebaut sind.
Bei der Intel zeigt sich das in der Praxis extrem und wie kennen es unter dem 80%-Bug.
Theoretisch sollten die anderen SSDs es auch zeigen, aber man weiß eben noch nicht so genau, warum es gerade bei der Intel so krass auffällt und bei anderen nicht.
Selbst INtels Ingenieure wissen es wohl noch nicht. Wüsste man, woran es liegt, dann könnte man ja an einer Lösung arbeiten.
Sicher macht es bei der Intel am meisten Sinn, dieser 20% unpartitionierten Bereich zu spendieren, aber ich habe es eben auch bei der Mtron gemacht, auch wenn SLC etc...
Gruß
Druss
Vollkommen egal, ob MLC oder SLC bzw. ob 1 Bit oder 2 Bit pro Zelle gespeichert werden, die SSD löscht ja zunächst einmal nichts, sondern schreibt erst einmal dort weiter, wo noch nichts geschrieben wurde.
Irgendwann kommt ja dann der Punkt, an dem bei meiner 32GB SSD (um mal ein Beispiel zu haben) der gesamte Platz schon einmal beschrieben wurde und die SSD somit mal voll ist, auch wenn im System vielleicht nur 10GB auftauchen. In Wirklichkeit wurde aber jede Zelle/jeder Baustein der SSD schon einmal beschrieben, bei den SSDs besteht ja im Gegensatz zu den HDDs nicht die Möglichkeit, Sektoren zu löschen.
Bei der SSD muss der elektrisch generierte Zustand der Zelle zurückgesetzt werden, bzw. die Zelle muss frei gemacht werden. Nun gibt es das nächste bauartbedingte Problem: einzelne Zellen können nicht gelöscht werden, sondern immer nur Blocks von 512kb.
Wenn die SSD also bei einer "vollen" Bestückung neues schreiben will, muss sie selbst für einen kleinen Speicherplatz von 4kb, der vielleicht noch vom letzten zu speichernden Volume der letzten freien Page oder Blocks übrig ist, einen 512kb großen Block löschen. Also muss dann erst einmal in den Cache gelegt werden, der Block wird gelöscht und dann wird aus dem Cache in den nun freien Block geschrieben.
Der Zustand der prinzipiell voll belegten SSD wird als "Low Level State" bezeichnet, weil dem User eine Geschwindigkeitsabnahme auffällt, die auf den oben beschriebenen und nun notwendigen Vorgang des Cache-löschen-schreiben zurückzuführen ist.
Wenn man nun einen Bereich partitioniert und einen (unpartitionierten oder partitionierten) Bereich frei lässt, dann kann die SSD für kleine, z.B. 4kb große zu schreibende Daten diesen Bereich auffüllen und braucht keinen Blcok zu löschen.
Im Prinzip ist das eine vereinfachte Defragmentierung, bei der die 512kb großen Blöcke mit 4kb großen Daten aufgefüllt werden können (natürlich vereinfacht ausgedrückt, wenn wie im Beispiel die überhängenden Daten immer nur 4kb groß wären).
Wie gesagt, dies betrifft auch die SLC-SSDs, weil diese bis auf die einzelne Zelle gleich aufgebaut sind.
Bei der Intel zeigt sich das in der Praxis extrem und wie kennen es unter dem 80%-Bug.
Theoretisch sollten die anderen SSDs es auch zeigen, aber man weiß eben noch nicht so genau, warum es gerade bei der Intel so krass auffällt und bei anderen nicht.
Selbst INtels Ingenieure wissen es wohl noch nicht. Wüsste man, woran es liegt, dann könnte man ja an einer Lösung arbeiten.
Sicher macht es bei der Intel am meisten Sinn, dieser 20% unpartitionierten Bereich zu spendieren, aber ich habe es eben auch bei der Mtron gemacht, auch wenn SLC etc...
Gruß
Druss
Zuletzt bearbeitet:
- Mitglied seit
- 02.08.2003
- Beiträge
- 2.317
ok danke für die erklärung aber was ich wissen wollte ist , wenn ich jetzt einen Breich partitioniere und frei lasse , oder auch unpartitioniert lasse , hat zwar die SSD noch reserven , weil ich den platz frei lasse und nicht nutze aber wenn auch der platz beschrieben ist von der SSD , dann sind wir doch wieder am anfang oder , also was bewirkt das genau , denn die SSD schreibt ja nach wie vor in den bereich auch wenn ich ihn nicht nutze
Es bringt eben genau garnix.
Wenn auf einer 30Gig SSD im laufe der Zeit 30Gig an Daten geschrieben wurden,auch wenn zum jetzigen Zeitpunkt nur 20Gig Daten für das BS real vorhanden sind,ist doch jede Zelle mindestens einmal beschrieben worden.
Win überschreibt bei jeder Sitzung ätliche Daten,diese Daten werden aus sicht der SSD nicht überschrieben sondern neu geschrieben bis tatsächlich kein freier Platz mehr vorhanden ist.
Dann kommt es eben dazu das die Zellen gelöscht und neu beschrieben werden müssen.
Warscheinlich noch viel früher,wenn du auf eine SSD eine 4K Datei schreibst wird in einen Block mit 512K geschrieben,also muss mit dem löschen und neu beschreiben noch viel früher begonnen werden,weil von dem 512K Block ja eigentlich noch 508K frei sind.
Diese restlichen 508K können aber nicht einfach beschrieben werden,sondern müssen erst gelesen,gecacht,modifiziert und noch geschrieben werden.
Wenn auf einer 30Gig SSD im laufe der Zeit 30Gig an Daten geschrieben wurden,auch wenn zum jetzigen Zeitpunkt nur 20Gig Daten für das BS real vorhanden sind,ist doch jede Zelle mindestens einmal beschrieben worden.
Win überschreibt bei jeder Sitzung ätliche Daten,diese Daten werden aus sicht der SSD nicht überschrieben sondern neu geschrieben bis tatsächlich kein freier Platz mehr vorhanden ist.
Dann kommt es eben dazu das die Zellen gelöscht und neu beschrieben werden müssen.
Warscheinlich noch viel früher,wenn du auf eine SSD eine 4K Datei schreibst wird in einen Block mit 512K geschrieben,also muss mit dem löschen und neu beschreiben noch viel früher begonnen werden,weil von dem 512K Block ja eigentlich noch 508K frei sind.
Diese restlichen 508K können aber nicht einfach beschrieben werden,sondern müssen erst gelesen,gecacht,modifiziert und noch geschrieben werden.
Zuletzt bearbeitet:
Es wird eben verzögert, bringt mithin also doch etwas. Verhindern lässt es sich freilich nicht.
Der unpartitionierte Bereich wird ja nicht beschrieben wie der partitionierte (dann wäre es eine Milchmädchenrechnung), sondern eben für die überhängenden Dateien genutzt. Das meinte ich mit der Quasi-Defragmentierung.
Zuletzt bearbeitet:
Hab´s editiert.
Ein SSD Controller nutz seine ganzen Zellen wie es ihm beigebracht wurde,der weis nix von deiner Partition.
Das ist auch gut so,da er die Schreibzugriffe ja auf alle Zellen gleichmäßig verteilen soll.
Das hier unbedingt mal lesen,sehr interessant und mehr und bessere Infos drinne als im Anand Artikel.
http://www.effizienzgurus.de/main/index.php?content=article&action=view_spec_article&article_id=624
Das ist auch gut so,da er die Schreibzugriffe ja auf alle Zellen gleichmäßig verteilen soll.
Das hier unbedingt mal lesen,sehr interessant und mehr und bessere Infos drinne als im Anand Artikel.
http://www.effizienzgurus.de/main/index.php?content=article&action=view_spec_article&article_id=624
Zuletzt bearbeitet:
- Mitglied seit
- 04.02.2008
- Beiträge
- 483
Schon richtig, aber wenn auf der SSD nur noch wenig frei ist, enthalten fast alle 512k Blöcke bereits Daten, die deshalb nicht einfach gelöscht werden können. Wenn jetzt die SSD einen neuen Block löschen muss um wieder neue Daten schreiben zu können muss sie irgendwann anfangen erstmal die anderen Daten in dem zu löschenden Block so umzuorganisieren, dass sie nicht verloren gehen. Sie muss also solange andere, nur teilweise gefüllte Blöcke zusammenlegen bis sie wieder einen Block ohne Daten hat und ihn komplett löschen kann ohne bei Stromausfall einen Datenverlust zu riskieren. Erst danach kann sie wieder einen Block vollschreiben. Beim nächsten Block geht dann das gleiche Spiel von vorne los. Je weniger voll die SSD ist umso weniger häufig und aufwendig muss sie logischerweise defragmentieren um auch dann neue Daten speichern zu können, wenn alle Blöcke schon mal beschrieben wurden. Klar halten sich die SSDs eine Reserve frei, die sie dem OS gar nicht als verfügbar melden, u.a. um derartige Umkopiervorgänge auch bei fast voller SSD einigermaßen effizent ausführen zu können, aber auch diese Reserve muss sie sich nach dem Defragmentieren erst wieder freischaufeln um sie beim nächsten mal wieder zur Verfügung zu haben.
- Mitglied seit
- 02.08.2003
- Beiträge
- 2.317
aber ich dachte für die SSD gibt es keinen unpartitionierten bereich , egal ob ich einen mache oder nicht , die SSD nutzt trotzdem alle zellen , somit wäre die leere partition ja sinnbefreit , das verstehe ich nicht ganz , für windows ist es zwar ungenutzter speicher aber die SSD schreibt trotzdem rein was für Win dann eben nicht sichtbar ist , somit dürfte es null bringen ,das wollte ich von Druss01 erklärt haben , das wenn alles voll ist erstmal von der SSD gelöscht und wieder beschrieben werden muss war mir klar , nur das mit dem unpartitionierten bereich nicht , auch ist mir nicht klar was es bringen soll unter windows ein paar gigs frei zu lassen da die SSD ja eh versucht die daten gleichmäsig zu schreiben somit müsste sie ja auch die zellen benutzen die in windows noch als freier speicher angezeigt werden oder ?
WaDenKraMpF
Neuling
eben darum gehts ja... freier Speicher unter Windows =! freie zellen auf der SSD
es ist quasi egal ob man ne Partition über die ganze platte machst und davon nur 80% nutzt, oder ob man nur 80% partitioniert. Der SSD ist das im endeffekt scheiß egal.
Hat die Intel X25-M nicht eine interne defragmentierung laufen? Das war doch irgendwo mal angesprochen... wenn die platte aber zu voll wird (>80%) dann hat der controller nicht genügend freie zellen um die zellen umzuschichten und leere zellen ranzuschaffen... währe für mich ne logische erklärung, wenn es dort aber kein internes defragteil gibt (oder nen sonstiger algorithmus hokuspokus der aufräumt)
irgendwie gehts hier in 2-3 threads allgemein um SSD und funktionsweise und low level state...
es ist quasi egal ob man ne Partition über die ganze platte machst und davon nur 80% nutzt, oder ob man nur 80% partitioniert. Der SSD ist das im endeffekt scheiß egal.
Hat die Intel X25-M nicht eine interne defragmentierung laufen? Das war doch irgendwo mal angesprochen... wenn die platte aber zu voll wird (>80%) dann hat der controller nicht genügend freie zellen um die zellen umzuschichten und leere zellen ranzuschaffen... währe für mich ne logische erklärung, wenn es dort aber kein internes defragteil gibt (oder nen sonstiger algorithmus hokuspokus der aufräumt)
irgendwie gehts hier in 2-3 threads allgemein um SSD und funktionsweise und low level state...
Zuletzt bearbeitet:
