Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Naja, nicht braucht ist Streitsache, aber einige der in der Pressemeldung beworbenen Funktionen hat Diskeeper schon seit langem in seinem Defragtool eingebaut, wie etwa die automatische Defragmentierung.
O&O mußte einfach nachziehen, so ist das. Die wollen ja keine Marktanteile abgeben. Und so werden auch Defragprogramme immer fetter. Wer nur einzelne Dateien defragmentieren möchte, sollte UltraDefrag oder das von Auslogics nehmen.
Übrigens, die Methoden des defragmentierens wurden in O&O 14 umgestaltet. Space, Name etc gibts nicht mehr. Heißt nun Optimize inkl Unterarten. Die Bootdefragmentierung defragmentiert anscheinend nur die Bootdateien statt die ganze Partition C, denn nach wenigen Sekunden ist der Spuk vorbei.
Da bei SSDs flash chips eingesetzt werden, ist es vollkommen egal, ob die Daten zusammen sind, oder verstreut sind. Da hier nur strom fließt, wird für die ganzen weiten Wege keine zusätzliche Zeit verbraucht, so wie es bei dem sich bewegenden Lesekopf von HDDs ist.
unter O&O lässt sich Trimm wie folgt manuell oder über eine selbst angelehgte Batch Datei ausführen
oodcmd.exe /TRIM:c (bzw. Laufwerksbuchstabe von SSD)
also bei mir funktioniert das Prima, und meine SSD ist nach der Ausführung um 34 Punkte AS SSD schneller.
Muss ja aber nichts heißen.
Es werden anch Herstellerangaben folgende SSd´s unterstützt:
SSD unterstützt den TRIM-Befehl. Dies sollte bei allen aktuellen Laufwerken mit der neuesten
Firmware gegeben sein, beispielsweise:
Intel X25-M G2 und X18-M G2 („Postville“)
SSDs mit Indilinx Barefoot (z.B. OCZ Vertex)
SSDs mit SandForce SF1200 oder SF1500 (z.B. OCZ Vertex 2)
SSDs mit Samsung RBB (z.B. OCZ Apex, Samsung PB22-J)
Samsung 470
SSDs mit neuesten Controllern von Toshiba
SSDs mit neuesten Controllern von Marvell (z.B. Crucial RealSSD C300)
SSD wird an einem SATA-Controller im AHCI-Modus betrieben
Rein technisch können TRIM-Befehle auch im IDE-Modus ausgeführt werden, diese blockieren
jedoch dann sämtliche Lese- und Schreibbefehle des Systems. Ohne AHCI bleibt somit
das System bei der Ausführung von TRIM für mehrere Sekunden bis Minuten regelrecht
stehen, was aus unserer Sicht für Kunden unzumutbar ist.
An RAID-Controllern oder an SAS-Controllern betriebene Laufwerke werden nicht unterstützt
SSDs im RAID-Verbund werden nicht unterstützt
SATA-Treiber muss TRIM-Befehle an SSDs weiterreichen können (ggf. Herstellerupdate erfragen)
Gegenwärtig können nur die neuesten Treiber von Intel (iastor) sowie der Windows-eigene
AHCI-Treiber von Microsoft (msahci) TRIM-Befehle weiterreichen
5
O&O Defrag
und Solid State Drives www.oo-software.com
Da bei SSDs flash chips eingesetzt werden, ist es vollkommen egal, ob die Daten zusammen sind, oder verstreut sind. Da hier nur strom fließt, wird für die ganzen weiten Wege keine zusätzliche Zeit verbraucht, so wie es bei dem sich bewegenden Lesekopf von HDDs ist.
So ganz stimmt das nicht, denn auch Flash wird Blockweise adressiert und man muß dann immer einen ganzen Block lesen, auch wenn man nur einen Teil davon benötigt. Da die Blöcke größer als die üblichen 4k Sektoren sind, macht es schon einen Unterschied, ob der nächste Sektor der Datei im gleichen Block steht oder in einem anderen. Deswegen ist die 4k Performance bei SSDs ja auch deutlich geringe als die seq. Übertragungsraten. Dank NCQ können die SSDs dann aber viel Blöcke gleichhzeitig ansprechen und dann bei parallelen Zugriffen deutlich profitieren.
Nur glaube ich kaum, daß O&O daran etwas optimieren kann, denn keine Software auf dem Rechner hat Zugriff auf die reale Verteilung der Daten auf den Flashbausteinen, da hier das Wear-Leveling dazwischen steht. Was die bieten scheint mir nur ein TRIM zu sein, wie es Vista und Win7 schon habe, Intel es mit seinem SSD Toolkit bietet und andere SSDs herstelller auch. Diese herstellereigenen Tools können vielleicht sogar mehr, wenn sie auch das Wearleveling beeinflussen. Herstellerübergreifend wird O&O das aber kaum bieten können, wenn es überhaupt bei eines SSD funktioniert.
Am besten ist ehrlich gesagt noch MyDefrag, welche auch noch Freeware ist, auch wenn der es ebenfalls einen Modus für Flash bietet. Sowas kann aber nur ein Flashspeichern funktionieren, die kein Wearleveling haben.
Was die bieten scheint mir nur ein TRIM zu sein, wie es Vista und Win7 schon habe, Intel es mit seinem SSD Toolkit bietet und andere SSDs herstelller auch.
Es ist denke ich generell für SSd´s geignet wo es keine Zusatzsoftware gibt was erkennen lässt das TRim überhaupt irgendwann einmal läuft und in welchen Abständen. Mit Version 14 hat man die Möglichkeit entweder manuell zu trimmen durch den Befehl denn ich oben genannt habe oder im Programm Zyklen einzustellen, zumal das Programm für standrt HDD`s generell ganz gut zu gebrauchen ist und ich in siesem HDD´s und SSD´s mit einem Programm optimieren kann.
Sicherlich bedarf das noch ein paar test inwieweit das wirklich funktioniert und optimiert ist. Eine Defragmentierungssperre für SSD´s bietet das Programm auch und warnt davor.
Weiß jemand wo es aussagekräftige Tests zum Programm gibt?
Es ist denke ich generell für SSd´s geignet wo es keine Zusatzsoftware gibt was erkennen lässt das TRim überhaupt irgendwann einmal läuft und in welchen Abständen.
TRIM läuft nicht mal eben so, einmal pro Woche oder pro Monat oder so, sondern wenn etwas von der SSD gelöscht wird. Garbage Collection läuft von alleine auf der SSD, wenn sie Idle ist. Das sind aber zwei getrennte Sachen, zumal die Garbage Collection nicht von Rechner beeinflusst wird bzw. werden kann.
Wenn eine Datei gelöscht wird, danns markiert das Betriebssystem dies im Directory nur mit einem Flag, praktisch ändert sich also nur ein Bit. Wird der Platz wieder benötigt, dann schaut das Filesystem nach, welche LBA frei sind und es werden die nächten Daten dort geschrieben. Bei einer HDD ist das kein Problem, man scheibt einfach über die alten Daten, da man die magnetische Ausrichtung jederzeit und beliebig oft ändern kann.
Bei einer SSD ist das komplizierter, da gibt es erstmal zwei Blöcke, die Schreib-Leseblöcke und die noch größeren Löschblöcke. Flashbausteine werden blockweise angesprochen, d.h. man adressiert einen Block und einigen kB und muß diesen dann komplett lesen oder schreiben. Bevor man aber schreiben kann, muß der Block geflasht worden sein, nur werden noch viel größere Bereiche mit einmal geflasht als geschrieben bzw. gelesen werden, das können durchaus 16, 32 oder 64 Schreib-Leseblöcke sein. Wenn man nun nur einen davon beschreiben möchte, dann muß man alle anderen die auch belegt sind, vorher auslesen (werden bei flashen ja auch gelöscht) und dann alle wieder zurückschreiben (Read-Erease-Write) und das dauert eben sehr lange.
Obendrauf kommt noch, daß man jede Zelle nur so 10.000 (bis 30.000)mal löschen kann (MLC, SLC das zehnfache). Verteilt man also die LBAs des Filesystems einfach starr auf den Speicherbereich des Flashs, so wären diese Zyklen bei häufig geänderten Daten schnell aufgebraucht (was wie ein defekter Sektor einer HDD wäre) und man hätte die gleichen Fragmentierungsprobleme wie bei einer HDD.
Deshalb gibt es eine Umverteilung, Wear Leveling genannt. Da merkt sich der Controller, welche Blöcke wie oft geflasht wurden, verändert die Zuordung zwischen den LBAs und den Flashbereichen und kopiert auch ggf. Daten um.
Ohne TRIM kann der Controller aber nun nicht wissen, ob er da nicht ggf. Daten von schon gelöschten Dateien umkopiert und erkennt erst, daß die Daten gelöscht sind, wenn das Betriebssystem die gleichen LBA wieder beschreiben will. Dann kann er die neuen Daten bestenfalls auf einen anderen Bereich schreiben, der gerade frei und geflasht ist, dazu darf die SSD aber halt nicht total voll sein. Schlimmstenfalls hat er nicht genug freie Bereiche und muß langsame Read-Erase-Write Zyklen einlegen und dann ist die Geschwindigkeit eben halt sehr bescheiden.
Garbage Collection macht nun folgendes: Wenn hier und dort ein paar freie Blöcke sind, dann werden die eben möglichst zusammengelegt um den ganze freien Platz in weitgehend in den gleichen Löschblöcken zu haben. Das kostet aber halt mehr Flashzyklen, also Lebensdauer. TRIM spart Löschzyklen, weil eben tote Daten nicht mehr umkopiert werden, Undelete ist aber halt auch nicht mehr möglich. Zusammen ermöglicht beides, die Performance der SSD möglichst immer auf dem Niveau des Neuzustandes zu halten, einzeln schafft es jede von beiden normalerweise nicht wirklich dauerhaft.
Auch wenn die Daten im Flash also durchaus ähnlich fragmentiert liegen wie auf einer HDD, so kann das Betriebssystem doch nie feststellen, wo wirklich was gespeichert ist. Dafür ändert sich die Zuordnung von logischen Blöcken zu Flashadresssen eben zu oft und vor allem wird diese ja nicht nur aus Performancegründen vorgenommen, sondern eben in erster Linie um die Flashzyklen möglichst gleichmäßig über den ganzen Bereich zu verteilen. Wenn man also wirklich die Datenanordung auf der SSD optimieren wollte, dann müßte man eben gerade auch diese Informan kennen und berücksichtigen und trotzdem würde jedes Umverteilen von Daten die Lebensdauer verringern, die Lesegeschwindigkeit nicht erhöhen sondern nur die Schreibleistung verbessern.
Ergänzung ()
Was jetzt zu kurz kam:
Eine HDD / SSD wird in logischen Blöcken adressiert (LBA), die bisher immer 512Byte groß sind (auch bei den neuen mit Advanced Format von 4k). Damit kann man 2T adressieren, darüber braucht man dann wirklich mehr, aber die 4k Platten werden logisch noch immer 512Byte weise angesprochen.
Während das Betriebssystem ohne TRIM beim Löschen einer Datei nur das eine Bit "Gelöscht" setzt, wird durch TRIM der SSD mitgeteilt, welche LBAs von der Datei belegt wurden. Dies Information gibt es ja nur im Dateisystem und ist daher nur dem Betriebssystem bekannt. Wann genau das Betriebssystem dies nun macht, ob gleich nach dem setzen des "Gelöscht" Flag der Datei, in einem ruhigen Moment danach, wenn die SSD einen bestimmen Füllungsgrad erreicht hat, wenn eine bestimme Menge an Daten gelöscht wurde oder eben periodisch, ist letztlich egal.
Mit den Tools wie dem von Intel kann man es eben periodisch machen, dann prüft das eben, welche Dateien als gelöscht markiert wurden und teilt deren Blöcke der SSD mit.
Ja unter windows 7 64 bit. Werde das aber frühstens in ein paar wochen nochmal testen wenn die SSD länger in Verwendung war. Habe es aber manuell über ausführen gemacht.
Ist das Windows orginal auf die SSD im ACHI Modus installiert worden? Wenn ja, dann sollte des TRIM schon aktiviert und das Deframentieren deaktiviert haben.
Das so ein Deframentieren durchaus ein paar Pünkten bringen kann ist klar, den danach werden die Daten auch innerhalb eines Blocks schön zusammengefasst. Wearleveling wird logischerweise mit Blockgrößen entsprechend den Löschblocken arbeiten, eine kleinere Aufteilung wäre ja auch nicht nötig. Die Schreib-Leseblöcke sind immer noch größer als die 512Byte eines LBA und wenn sie nun größer als die Sektoren sind, was durchaus üblich ist, dann bei entsprechender fragmentieren Dateien diesen auf mehr Schreib-Leseblöcke verteilt sein, als wegen der Dateigröße nötig. Defragmentieren, also das Umordnen der Dateien auf aneinanderfolgende Sektoren, behebt diese dann natürlich, allerdings ist halt der Vorteil sehr viel geringer als bei HDDs.
Garbage Collection bewirkt etwas ähnliches und zwar, daß die Schreiblese- und Löschblöcke jeweils möglichst ganz gefüllt oder ganz frei sind. Dabei weiß der SSD Controller aber naütlich nicht, welche LBAs nun zu einer Datei gehören bzw. auch noch aufeinander folgend sind. Die Lesengeschwindigkeit steigt dadurch nicht, beim Schreiben ändert läuft beides auf das gleiche heraus, nur das Garbage Collection natürlich mit dem Wearleveling zusammenhängt und die Daten bisher selten gefläshter Löschblöcke bevorzugt zum Auffüllen von Lücken in anderen nutzt, damit diese wieder mal geflasht werden.
Der Preis für etwas mehr Lesegeschwindigkeit ist dann halt viel mehr Verschleiß der Zellen, weil das Defragmentieren natürlich nicht weiß, ob die Fragmentierung der Datei auch auf Schreibleseblockeben besteht .
Wieso sollte man das Windows7-Defragmentieren abschalten? Wie schon geschrieben hat es ja gewisse Vorteile, wenn die Sektoren einer Datei möglichst wenig Blöcke belegen. Im Gegenzug stehen mehr vollständig leere Blöcke zum Schreiben zur Verfügung. Außerdem liegt es nahe, dass beim Defragmentieren die leer gewordenen Blöcke unter Windows 7 nun per TRIM der SSD auch vermittelt werden.
Ich defragmentiere in mehrmonatigem Abstand und die SSD ist zu 95% voll. Beim AS SSD steigt die Schreibgeschwindigkeit wieder auf Neuzustand.
Die Daten werden aber nicht weniger Blöcke belegen wenn du sie von A nach B schiebst. Und es stehen nicht mehr Blöcke zum Beschreiben zur Verfügung. Nämlich genausoviele.
Das Einzige was du da machst ist, die jetzt leeren Blöcke wieder zu beschreiben, neue leere Blöcke herzustellen und diese dann zu löschen.
Viel einfacher ist es da, einfach den freien Speicherplatz mit Nullen zu überschreiben und das wars. So erhälst du auch schon die Mehrleistung die du ansprichst.
Mich würde es interessieren ob die Erase Funktion der neuesten HDTune Version einen Vorteil bringt wenn man kein TRIM im Laufwerk hat. So kann man den freien Speicherplatz mit Nullen beschreiben was sie ja dann wieder schneller macht.
Die Optimierung der Datenstruktur auf der SSD solltest Du der Firmware sowie einer evtl. vorhandenen Toolsoftware vom Hersteller der SSD überlassen.
Die althergebrachte Defragmentierung optimiert die Datenanordnung für rotierende Magnetscheiben (kurz Festplatte oder HDD genannt) und bringt bei einer SSD rein gar nichts.
