Garbage Collection vs TRIM

[Morpog]

Datei wird gelöscht-> Belegte sektoren werden getrimt.
Wo liegt dein Problem? Wozu index?

Er meint wohl falls der SSD Controller das trimmen in ne IDLE time legen möchte.
Aber meiner Meinung nach sollte das trimmen immer sofort geschehen, sonst ist es recht sinnlos.

---------- Beitrag hinzugefügt um 23:44 ---------- Vorheriger Beitrag war um 23:43 ----------

Datei wird gelöscht-> Belegte Sektoren(sind bekannt stehen in MFT) werden getrimt.
Wo liegt dein Problem? Wozu index?

Edit: zu langsam...

Übrigens: Schau wie TRIM-Tool arbeitet: Es legt eine Datei die den ganzen freien Platz belegt und schickt TRIM-Befehl an genau die Sektoren wo sie liegt und löscht sie anschließend.

MFT ist doch noch NTFS Ebene, oder?
LBA wäre doch richtig.

 

[nsa666]

In der MFT stehen die LBA-adressen die die Datei belegt.

Sofort wäre schlecht weil TRIM dauert. Würde die arbeit verlangsamen. Win7 hat einen Puffer dafür und löst TRIM später aus.

 

[Morpog]

In der MFT stehen die LBA-adressen die die Datei belegt.
Sofort wäre schlecht weil TRIM dauert. Würde die arbeit verlangsamen. Win7 hat einen Puffer dafür und löst TRIM später aus.

OK, so machts natürlich sinn.
Jetzt wo du es sagst fällt mir das auch wieder ein. Das war ja auch das Problem der TRIM Implementation im LINUX Kernel, da dort die TRIM Befehle sofort rausgingen.

 

[A_H]

In der MFT stehen die LBA-adressen die die Datei belegt.

Was genaueres habe ich gerade nicht gefunden:
http://www.ntfs.com/ntfs-mft.htm
LBA-Adressen, einzeln? Vermutlich Bereiche von - bis, Extents. Gibt es ein Gegenstück zur MFT für die freien Bereiche? Wenn nein, dann müssen die freien Bereiche ermittelt werden. Gibt es unter Vista eine Tabelle für gelöschte Bereiche, unter W 7? Wann würde die aktualisiert?

Hier im Forum wird für SSDs von der Defragmentierung abgeraten - die Leute denken zu kurz. Dann würden keine Extents mehr zusammengelegt und es könnte eng werden in der MFT. Bei Notebooks mit kleinen Platten gab es Fälle, da konnte ein Servicepack ohne wenigstens eine Defragmentierung seit der Systeminstallation nicht installiert werden - freue mich schon auf den Tag, wo das den Experten hier passiert.

 

[nsa666]

Natürlich speichert ntfs auch die freien bereiche(in der $Bitmap). Wie sollte es sonst neue Dateien anlegen ohne vorher MFT komplett duchsuchen zu müssen...
Im normalfall werden die freien cluster beim löschen da eingetragen.

 

[Morpog]

Hier im Forum wird für SSDs von der Defragmentierung abgeraten - die Leute denken zu kurz. Dann würden keine Extents mehr zusammengelegt und es könnte eng werden in der MFT. Bei Notebooks mit kleinen Platten gab es Fälle, da konnte ein Servicepack ohne wenigstens eine Defragmentierung seit der Systeminstallation nicht installiert werden - freue mich schon auf den Tag, wo das den Experten hier passiert.

Microsoft selbst schaltet nicht ohne Grund automatisch bei erkennen einer SSD die automatische Defragmentierung ab in W7.

Aber ja, einmal im Jahr machts schon sinn. MTRON emfiehlt dies sogar.

 

[Sukrim]

Nochmal: Getrimmmt wird von Win7 wenn man den Papierkorb leert. Bis dorthin weiß Windows also noch ganz fix, wo die Daten liegen, sonst könnte man sie ja auch nicht mehr wiederherstellen...

Ob ich jedesmal den gesamten freien Speicherplatz als "TRIM das mal" and SSD schicke, oder nur ausgewählte Bereiche ist egal, das SSD muss sich schon selbst überlegen, was es mit der Info macht - und dass schon als leer markierte Bereiche (die einfach überschrieben werden) nochmals als leer markiert werden, schadet ja nicht.

Edit: Mtrons SSDs haben auch kein Write Combining... daher hilft Defragmentierung auch wirklich was (in Maßen logischerweise). Bei einem modernen SSD freut sich maximal Windows darüber, das SSD hat wohl weniger Freude damit.

 

[Morpog]

Nochmal: Getrimmmt wird von Win7 wenn man den Papierkorb leert. Bis dorthin weiß Windows also noch ganz fix, wo die Daten liegen, sonst könnte man sie ja auch nicht mehr wiederherstellen...

Ich lösch eh immer endgültig (shift+entf).

 

[DoubleJ]

Ich lösch eh immer endgültig (shift+entf).

Dann könntest du den Papierkorb doch eigentlich auch gleich ganz deaktivieren, oder?

 

[A_H]

Dann könntest du den Papierkorb doch eigentlich auch gleich ganz deaktivieren, oder?

Ja, ich auch

---------- Beitrag hinzugefügt um 01:50 ---------- Vorheriger Beitrag war um 01:41 ----------

Diese altmodischen Betriebssysteme XP, Vista, Windows 7 usw. und diese mistigen Treiber von Intel passen absolut nicht zu diesen tollen, progressiven, innovativen SSDs. Oder anders herum: die SSD-Sparte wartet darauf, dass die Softwaresparte die Zuarbeit macht, ohne daran zu verdienen - und der Kunde ist (momentan) in den Popo gekniffen.

 

[KeinNameFrei]

Meinst du das jetzt wirklich ernst, oder übst du dich als Forumtroll um zu sehen wer anbeißt?

 

[raptor55]

Meinst du das jetzt wirklich ernst, oder übst du dich als Forumtroll um zu sehen wer anbeißt?

*LOL*déjà-vu!

 

[A_H]

Meinst du das jetzt wirklich ernst, oder übst du dich als Forumtroll um zu sehen wer anbeißt?

Ich meine anbeißen und mitdenken und diskutieren.
Schau in Deinen Gerätemanager. CD und HD sind ziemlich verschiedene Geräte mit verschiedenen Geräteklassen (oder wie heißt das?), obwohl sie am gleichen SATA-Controller hängen. Sie haben völlig unterschiedliche Dateisysteme mit teilweise ganz anderen Treibern, selbst innerhalb von CD/DVD /Blue Ray etc..Das wäre doch auch für SSD denkbar und machbar - mit entsprechendem Aufwand für die SSD-Hersteller. Die SSD wären dann von allen Unzulänglichkeiten der bisherigen Hardware und Treiber abgekoppelt. Aber so ist es billiger und bequemer für die SSD-L...eute, die behaupten, dass manche Intel-Treiber schuld sind und ständig auf frühere Firmwarefehler von Festplatten hinweisen.

Und klar werden die Betriebssysteme von deren Herstellern auch hinsichtlich neuen Datenträgern weiter entwickelt. Aber was hindert die SSD-Hersteller daran, einen brauchbaren Service zu schreiben, der im Hintergrund trimmt usw.. Da braucht doch niemand auf Windows 7 zu warten; Xp und Vista gibt es ja auch noch.

 

[Eggcake]

Eben, im Hintergrund trimmen geht mit Inteltreibern nicht, da können die SSD-Hersteller noch so tolle Software schreiben.

Zudem ist der finale Trim-Command noch garnicht so lange spezifiziert. Geduld.

 

[7oby]

Diese altmodischen Betriebssysteme XP, Vista, Windows 7 usw. und diese mistigen Treiber von Intel passen absolut nicht zu diesen tollen, progressiven, innovativen SSDs. Oder anders herum: die SSD-Sparte wartet darauf, dass die Softwaresparte die Zuarbeit macht, ohne daran zu verdienen - und der Kunde ist (momentan) in den Popo gekniffen.

Gehe ich nicht d'accord.

Stell' einen unvorhereingenommenen User vor ein System mit SSD u. das gleiche nochmal mit HDD. Welches findet er besser? Er wird sofort das SSD System - schon beim Booten - identifizieren. Hier ist überhaupt niemand in den Popo gekniffen. Jeder kann - so er sich eine SSD kauft - von dem Performanceboost unmittelbar profitieren. Selbst auf Netbooks mit schwachen CPUs profitiert der User!

Wenn ich mir vergegenwärtige wie vor der SSD-Era hier im Forum um 0,1ms in der Zugriffszeit bei 7200er HDDs gefeilscht wurde. Dabei war das völlig marginal u. in der Tat eine 10 Jahre alte IBM DTLA 10GB Platte hat Zugriffszeiten in der gleichen Größenordnung:
http://www.tomshardware.com/de/kapazitaet-schlaegt-leistung,testberichte-237298-11.html

15 Jahre war Stillstand bei Massenspeichern. Keine optischen Wunder-Laser, Magneto-Schlagmichtot konnten irgendetwas bezwecken. Stattdessen wurde das OS immer komplexer und die Bootzeiten stiegen von OS zu OS Version.

Jetzt zum ersten mal kann man eine SSD nehmen seit ca. 1 Jahr (um von den anfänglichen SSD Lags abzusehen) u. hat wahrhaftige Faktor 2x bis 3x je nach Anwendung!

Und dann kommt A_H hyped die "progressiven, innovativen SSDs" und beschimpft Betriebssysteme als "altmodisch" und Treiber als "mistig".

Dabei wollen wir mal festhalten, dass es 2x die Indilinx Controller waren, die jeweils in bestimmten FW Versionen zu Datenkorruptionen führen konnten! Bis eine SSD optimal in das OS mit allen Features (TRIM, GC) integriert ist, das ist ein kontinuierlicher Optimierungsprozess. Laggende SSDs und SSDs mit Datenkorruption kann keiner gebrauchen - mir geht die Entwicklung hier manchmal etwas zu schnell.

Beim Filesystem u. auch bei der Verwendung von SSDs ist das letzte Wort noch nicht gesprochen. Man könnte ein SSD genausogut als persistenten Cache Verwenden. So wie man CPUs mit L3 u. ohne L3 Cache einsetzen kann, kann man theoretisch ein bestehendes HDD System um SSDs erweitern - während dem Betrieb. Thema hybrid-System/readyboost bloß eine Nummer größer. Natürlich ist das langsamer als SSD only, aber universeller.

--

TRIM ist kein Geheimnis, sondern öffentliche Spek, das eine Firmware + Treiber + OS entweder unterstützen kann oder nicht. Das OS kann sich dann noch überlegen wann u. wie häufig es trimmt.

GC lebt nur in der Firmware der SSDs. Wird damit wohl auch erstmal Betriebsgeheimnis bleiben wie's implementiert ist. Ist Optimierungspotential des SSD Herstellers. Wie groß das Geschrei gerade bei der FW 1819 für die Indilinx Controller bzgl. GC ist, hast drüben sicher schon mitbekommen. Wieder die SSD Hersteller, die ihre Suppe nicht ausgelöffelt bekommen.

Sowohl Microsoft als auch die Linux Community verhalten sich bzgl. SSDs äußerst löblich. Von Datenverlust hab' ich noch nichts gesehen. Bei den SSD Herstellern war in der Vergangenheit (Lags, Datenverlust, vermind. Schreibleistung bei GC) nicht immer alles Top!

 

[Sukrim]

Wobei gerade von OS/Softwareseite noch immer extremes Optimierungspotenzial vorhanden ist - Stichwort LogBased-Filesystem. Man braucht sich nur anschauen, wie MFT auf SSDs so abgeht (nein, das ist kein einfacher Cache im RAM!).

Desweiteren geht es jetzt erst mit Consumer-SSDs so richtig los, bis sich mal das Image von "Freakhardware" zu "sinnvollere Investition als der auf 2 GHz übertaktbare RAM" geändert hat dauert's auch noch ein bisschen.

Das Problem ist eben (wie schon vor 1-2 Jahren angesprochen) wie "klug" SSDs sein sollen/müssen. GC ist ein schwieriger und komplexer Vorgang, den durchaus das OS auch übernehmen könnte. SSDs wären dann nicht viel mehr als Flashchips + ein Interface um sie anzusprechen und das OS könnte dann seine Algorithmen perfekt so ablaufen lassen wie es will.
Anscheinend ist es derzeit den Herstellern aber lieber, das SSD als schnelles HDD dem OS gegenüber zu "tarnen" - TRIM ist da schon mal eine erste Annäherung und ich denke, das wird diese in Richtung weitergehen. Am Ende wird man wohl Flash ähnlich wie RAM erweiterbar auf Mainboards verbauen, Intel hat da eh schon sowas in die Richtung geplant.

 

[A_H]

Anscheinend ist es derzeit den Herstellern aber lieber, das SSD als schnelles HDD dem OS gegenüber zu "tarnen"

Nach so einer Formulierung hatte ich die ganze Zeit gesucht.

Diese Tarnung hat eben Vor- und Nachteile. Wobei das unterschiedlich auf Hersteller und Kunden verteilt sein könnte.

 

[7oby]

Anscheinend ist es derzeit den Herstellern aber lieber, das SSD als schnelles HDD dem OS gegenüber zu "tarnen"

Das ist nicht ganz fair.

Diese "Tarnung" hilft im Moment allen die Verantwortlichkeiten klar zu regeln. Wofür ist heute das OS zuständig u. wofür die SSD. Siehe GC u. TRIM. Diese Tarnung ist eine Zugriffsschicht die gut erprobt ist u. selbst Features wie NCQ, die Race Conditions auslösen können (read before write!) sind 100% getestet u. wasserdicht.

Wenn man jetzt alles in einen großen Topf wirft, dann ist's zunächst mal langsamer u. das Fehler finden viel schwieriger.

Die SSDs haben sich in den letzten 2 Jahren Raketenmäßig entwickelt. Hat die SSD von morgen MLC oder SLC? Wieviele interne Flash Channels kann sie? Wie groß sind die Eraseblöcke morgen? Wie groß ist der Cache auf der SSD? Alles Parameter, die eine optimale Performance beeinflussen.

Es gibt derzeit schon eine Inflation an Flashbased Filessystemen. Hier mal 12 Stück (und das ist noch ohne MFT):
http://en.wikipedia.org/wiki/List_o...imized_for_flash_memory_.2F_solid_state_media

Welche unter welchen Bedingungen gut sind das muss sich erst noch zeigen. Sollte das OS wirklich Wear Leveling machen? Ist es da besser als die Firmware? Wohl kaum.

Lasst die SSD erstmal so konsolidieren u. bzgl. Ihrem internen Aufbau u. Performanceparameter konvergieren. Und wenn das passiert ist kann man das perfekte Filesystem dafür immer noch schreiben.

Der schnellste u. sicherste Weg ist in meinen Augen genau das was im Moment passiert: Etablierte Schnittstellen (ATA) u. selbst das Aufbohren dieser scheint ja teilweise unlösbare Probleme zu machen (TRIM Kommando in manchen Firmwares fehlerhaft).

P.S.: In dieser Transitionsphase HDD -> SSD ist's auch ein unschätzbarer Vorteil, dass beide mit NTFS u. als HDD angesprochen werden können. Ein Acronis Backup von HDD kann ich auf SSD einspielen (u. wenn's dann unbedingt sein muss das Alignment dabei anpassen). Angenommen die SSD hätte ein neues Filesystem - dann könnte ich zwischen HDD / SSD nicht so einfach hin und her. Ein unschätzbarer Vorteil gerade jetzt wo Firmwares so im Fluss sind u. teilweise eben Daten korruptieren, so dass ein Backup eingespielt werden muss.

 

[A_H]

@7oby
Dann soll man aber auch nicht auf den alten Zopf schimpfen und damit die Kunden veralbern. Und bitte schön hinten anstellen: wer zuerst kommt, der mahlt zuerst. Die Treiberentwickler für HDDs konnten ja nicht ahnen, was noch alles kommt und was sich täglich bei der SSD ändert.

 

[7oby]

Ich seh' das eigentlich sehr entspannt. Solange ein Anand den SSD Herstellern erläutern kann wie sie ihre SSDs zu designen haben:

I wrote an email to Ryan Petersen, OCZ’s CEO. I [...] told him that while the Vertex’s performance was [...] unacceptable for anything other than perhaps extremely light, single-tasking usage.

I told him it sucked. He said that wasn’t fair. We argued over email but he came back and asked me what I needed to see to make the drive better.

I told him I’d need an average response time in the sub-1ms range and a max latency no worse than Intel’s 94ms.
[...]
Ryan said we’d lose some sequential write performance. The drive would no longer be capable of 230MB/s writes, perhaps only down to 80 or 90MB/s now. I told him it didn’t matter, that write latency needed to come down and if it were at the sacrifice of sequential throughput then it’d be fine. He asked me if I was sure, I said yes.

http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=20

Natürlich weiß ich, dass nicht OCZ die Vertex designed sondern Indilinx, aber dieser Dialog sagt doch eigentlich alles, oder?

Indilinx weiß überhaupt nicht was sie überhaupt optimieren sollen. Passt perfekt ins Bild zur soeben erschienen FW 1819. TRIM und GC sehe ich als das kleine 1x1. Und bevor man sich in der Schule an das große 1x1 macht (= Filesystemoptimierungen + generelle SSD Verwaltung im OS), sollte man erstmal das kleine 1x1 beherrschen. Also Indilinx u. natürlich Intel auch, sollen erstmal ihr TRIM + GC auf die Kette bekommen u. dann schauen wir weiter. Intel hat ja bisher weder TRIM noch IASTOR.SYS released!

--

Ich sehe immer noch große Skepis beim Verbau von SSDs in Enterprise Datenbanksystemen. Obwohl gerade diese immens von der Performance profitieren könnten. In Realbenchmarks versägt eine intel SLC 8x 15.000 rpm SAS drives:

One X25-E is 66% faster than eight (!) 15000RPM SAS drives

http://www.anandtech.com/IT/showdoc.aspx?i=3532&p=11

Gerade hier ist einfach wichtig, dass die Hersteller von SSDs absolute Stabilität liefern u. nicht irgendeinen Voodoo Zauber. Denn wenn sie auch dort SSDs verkaufen wollen, dann muss das Zeug einfach laufen u. die jetzigen Vorbehalte entkräftigt werden.

 

[Sukrim]

Das ist nicht ganz fair.

Diese "Tarnung" hilft im Moment allen die Verantwortlichkeiten klar zu regeln. Wofür ist heute das OS zuständig u. wofür die SSD. Siehe GC u. TRIM. Diese Tarnung ist eine Zugriffsschicht die gut erprobt ist u. selbst Features wie NCQ, die Race Conditions auslösen können (read before write!) sind 100% getestet u. wasserdicht.

Wenn man jetzt alles in einen großen Topf wirft, dann ist's zunächst mal langsamer u. das Fehler finden viel schwieriger.

Genau deswegen finde ich das auch nicht unbedingt schlecht, allerdings wäre es toll zumindest für "Linuxfreaks" oder sonstige Bastler auch Lösungen auf dem Markt zu haben, die dann schon eienn Vorgeschmack auf weiter in der Ferne liegende Entwicklungen (CPU mit Flashcontroller eingebaut) bieten können. Mit einem SSD kauft man sich derzeit eine kleine Black-Box bei der man oftmals nicht mal weiß sondern nur "fühlen" kann ob da gerade GC läuft. Gerade in der "Kommunikation" der SSDs zum Anwender (sowas wie SMART für SSDs - rudimentär geht's ja, aber das ginge auch noch besser... SSD-z anyone?) gehört noch gewaltig aufgeholt um auch mit gewissen Mythen aufräumen zu können.

Wer erst in 5 Jahren umsteigt, wird vielleicht nicht mal ein SATA-Gerät als SSD bekommen... wer weiß?
Allerdings heißt das NICHT, dass aktuelle SSDs deswegen schlecht oder nicht empfehlenswert wären - das sind eben nur Punkte, an denen Firmware-/Softwareseitig baldigst nachgebessert gehört.

Auf lange Sicht wird man das sowieso realistisch gesehen mit Microsoft und Apple von Softwareseite und den größeren Chipherstellern und Flashherstellern von Hardwareseite ausverhandeln müssen, wie die das sehen und haben wollen. Was helfen mir z.B. 50-Kanal Controller, wenn das Betriebssystem darauf achtet, dass möglichst geringe Queue-Depths entstehen um HDDs nicht zu überfordern? Was können neue Dateisysteme an Vorteilen aus SSDs rauskitzeln? Was für neue Probleme werfen diese Dateisysteme auf?

Momentan geht es wohl wirklich erstmal darum, etablierte Technik zu nutzen. SSDs tun sich da besonders leicht, da sie einfach NUR Vorteile gegenüber HDDs bieten. Sobald diese sich jedoch mal als Systemlaufwerke durchgesetzt haben und auch die Firmwareküchen nicht mehr so wild brodeln wird's wieder spannend, da dann ein nächster Sprung von Softwareseite (eben Dateisysteme, "Parallelzugriffsmodus" von Betriebssystemen, Auslagerung oft genutzter Dateien auf bestimmte Datenträger...) ansteht während danach wohl wieder Hardwareveränderungen anstehen (Wozu SATA, wozu RAM...)

 

[7oby]

allerdings wäre es toll zumindest für "Linuxfreaks" oder sonstige Bastler auch Lösungen auf dem Markt zu haben, die dann schon eienn Vorgeschmack auf weiter in der Ferne liegende Entwicklungen (CPU mit Flashcontroller eingebaut) bieten können.

Die hätten sich auch ganz einfach ein Beispiel am Staging Bereich der Linux Treiber nehmen können:

. TRIM wird in die Firmware integriert, ist aber per default INAKTIV
. GC wird in die Firmware integriert, ist aber per default INAKTIV bzw. KONSERVATIV

Und wer die experimentellen Features mitesten möchte, der:

UDTOOL.EXE /ENABLETRIM
UDTOOL.EXE /ENABLEAGGRESSIVEGC

Man müsste nicht ständig Firmwares upflashen. Features könnten als rolling update aktiviert werden etc. Und wenn's reif genug ist, dann wird's im nächsten Firmware eben standardmäßig aktiviert.

 

[antiram]

die ssds ohne komischtechnik eingebaut gibts schon!!
das sind die alten jmicrons, mehr oder weniger bare metal flash mit statischem wearleveling drauf. das logfs kann man dann selber drüberinstallieren und am cleaner rumfrickeln

 

[Sukrim]

Problematisch bei den JMicrons ist aber eben nur, dass die Anbindung an den Flash zu wünschen übrig lässt...

und 7oby:
Meine Rede, nur weiß ich nicht genau, wie groß/komplex solche Firmwares wirklich sind oder sein können... wer weiß, vielleicht haben die sich da irgendwie in's Knie geschossen und müssen daher mit nur X KB maximalem Platz für Firmware auskommen oder so. Außerdem birgt jeder FW-Flash ein gewisses Risiko (und nichts anderes wäre es, wenn man Features aktiviert/deaktiviert) grundsätzlich wäre aber sowas zu begrüßen, gerne auch in Richtung des Mtron Tools, wo man noch ein paar Daten herauslesen kann. Irgendwie scheint es, als wäre es SSD-Herstellern irgendwie peinlich/unangenehm, wenn man detaillierte Infos über ein SSD leicht bekommen kann. Es gibt ja nicht mal einfache Tools von Herstellern, die einem schnell mal Verbrauchsgrad der Flashzellen (aus SMART-Werten), Seriennummer, Firmwareversion etc. darstellen.

 

[DoubleJ]

Irgendwie scheint es, als wäre es SSD-Herstellern irgendwie peinlich/unangenehm, wenn man detaillierte Infos über ein SSD leicht bekommen kann.

Ich würde eher sagen, da will niemand einem Konkurrenten auch nur den geringsten Vorteil bieten.

Allein die Tatsache, dass Indilinx z.B. eine 166 Mhz schnelle ARM7-CPU verbaut, lässt ja schon ahnen wie komplex die Firmware ist.

 

[Sukrim]

Naja, diese ganzen Infos sind ja nicht kritisch und könnten locker jetzt schon abgerufen werden (Crystal Disk Info versucht's ja schon).

Die 166MHz CPU sagt mir eher, dass Indilinx wohl zum Glück lieber groß plant. Leider kann man eben nur spekulieren, wie die Firmwaresituation wirklich aussieht und ob die fleißigen Asiaten da schon zig Sachen optimieren müssen um GC überhaupt in die FW quetschen zu können oder ob das erst der Anfang ist.

 

[Celsi]

So, nun hab ich den ganzen Thread gelesen und mir brummt die Birne. Nun kenn ich endlich den Unterschied zwischen GC und TRIM, ich dachte bisher immer, GC wäre ein in der Firmware verankertes TRIM.

Nun weiß ich aber leider auch, daß meine ungebrochen schnell rennende x25-m irgendwann einbrechen wird, denn INTEL hat sich ja entschieden, keine TRIM-fähige Firmeware für die G1 (nicht-Postville) rauszubringen.

Meine Fragen:

1) Wenn dieser Fall eintritt, gibt es ein Tool/Trick, mit dem ich den Einbruch wieder rückgängig machen kann ?
2) Für die Neuinstallation von Win 7 habe ich meine G1 erst vorgestern mit einem Tool namens 'MHDD' 'erased'. Bewirkt das einen komplette Löschung der Zellen, ist diese Vorgang empfehlenswert ?

Danke für jede Hilfe!

Gruss,
Celsi

 

[Bluebeard]

Auch nicht uninteressant:

http://www.heise.de/newsticker/meld...-Firmware-fuer-Windows-7-2-Update-842820.html

und

http://www.anandtech.com/storage/showdoc.aspx?i=3667

 

[DoubleJ]

Welche der zahlreichen SSDs des NAND-Flash-Marktführers Samsung ATA Trim bereits unterstützen, lässt sich mangels Dokumentation nicht herausfinden. Das SSD-Team von Samsung hebt aber die ATA-Trim-Vorzüge in seinem Blog hervor.

Samsung hat nun auch die einmalige Möglichkeit der einzige Hersteller mit TRIM-fähiger FW zu sein, die von Anfang an keinen Datensalat verursacht Bin gespannt, was sie daraus machen

 

[Bluebeard]

Wie gesagt testen wir schon eine Weile - leider noch nicht fertig - bisher gab es jedoch noch nichts zu bemängeln