Ich habe mir zu Weihnachten mal den Luxus SSD gegönnt. Jetzt habe ich alles installiert, die Karre läuft so wie sie soll und nun quält mich eine Frage: Macht es eigentlich noch einen Sinn SSDs zu defragmentieren? Durch die "Interne Fragmentierung" und die sehr strammen Zugriffszeiten könnte das doch eher nachteilig sein weil ich eh nur die endlichen Schreibzyklen pro Speicherzelle verbrate. Oder mach ich da gerade einen Denkfehler?
BLOS NICHT !!! das ist das schlimmste, was du den dinger antun kannst...nimm eine die trim unterstützt und gut
mal zur Erklärung: eine Festplatte ist eine drehende Scheibe wo ein einzelner Lesekopf die Dateien abruft - wie eine Schallplatte. Wenn eine Datei nun fragmentiert ist, muss der Lesekopf für diese eine Datei an verschiedene Stellen springen um die Datei vollständig lesen zu können. Eine SSD hat keine mechanisch bewegbaren Teile, also auch keinen Lesekopf - da gibt es nur Speicheradressen hinter dennen die Teile der Datei abgelegt sind. Ähnlich wie beim RAM. Ob die Speicheradressen dieser einen Datei nun aufeinanderfolgend oder willkürlich verteilt sind spielt keine Rolle, jede Speicherzelle ist einfach nur ein einzelner Lese- bzw. Schreibbefehlt Ein defragmentieren hätte zur Folge dass du unnötig Schreibbefehle auf die SSD gibts (und zwar ganz schön viele!!) Dieses unnötige beschreiben verringert die Lebensdauer deiner SSD, den eine SSD ist ein "Verschleißteil" und hat nur eine begrenzete Anzahl an Schreibvorgängen je Speicheradresse bevor sie defekt ist! Genau gleich wie beim USB-Stick.
@Klugscheißer: Danke für den langen Text der sicher vielen Leuten eine Hilfe ist (Wirklich sehr verständlich geschrieben, Respekt!) Aber ich behaupte einfach mal das ich "etwas" mehr Ahnung von HW habe als die meißten anderen Menschen, mir ging es nur darum mich nochmal zu vergewissern ob ich nicht doch evtl. einen Denkfehler drinnen hatte. (Man weiß ja nie). Aber du und auch dein Vorposter haben es mir bestätigt, damit wäre die Waffel dann gegessen und der Fred kann geschlossen werden. Und vielen dank nochmal an die schnellsten Antworten die ich je in einem Forum gesehen habe!
@Andi D. hab mir die "billigere" X18-M 80Gb gekauft, die kann zwar trim aber ich kann jetzt auch die schnelle nicht ergurgeln ob XP i386 SP3 das unterstützt? Kannst du mir das schnell beantworten? Wenn nicht dann gurgel ich weiter..... Danke
XP kann offenbar nicht. Aber da es nichts gibt, für das nicht irgendwer einen Hack gefunden hat, geht es eben irgendwie doch. Offenbar spaziert dann ein Daemon durch das Filesystem und TRIMt alle freien Blöcke: http://www.myce.com/news/ocz-first-to-introduce-trim-for-ssd-drives-15771/
Damit eine SSD auch länger hält, defragmntiert sich sogar die Festplatte selber. Sie versucht möglichst über den ganzen Flash die Daten so zu verteilen, dass jede Flashzelle gleichviel genutzt wird.
Das klingt ja seeehr interessant, mal abwarten wann irgendwer das tool für die Intels "umbastelt" oder Intel mal selber auf den Trichter kommt.....
@Markus Gräb: Das ist ja in Fachkreisen bekannt, nur wie effektiv die Firmware dabei ist steht auf einem anderen Blatt.....
Es ist erschreckend, dass selbst in einem Elektronikforen solche Fragen gestellt werden. Wo doch spätestens nach 3 Sekunden googeln und Hirnbenutzen klar ist, dass man SSDs nicht defragmentieren soll. Es ist schon schlimm genug, irgendwelche Geräte zu kaufen ohne sich vorher über ihre Eigenschaften, Features, Vorteile und Mängel informiert zu haben.
Doch, die soll man defragmentieren. Das ist gut für die Wirschaft.
Gäst schrieb: >Es ist erschreckend, dass selbst in einem Elektronikforen solche >Fragen gestellt werden. Wo soll man sie sonst stellen? im Radio bei Alexander Borell!? Ach ne ich hab ne Idee: Wir löschen alle Foren im internet und setzen die DNS konsequent auf google! - noch besser: wir verbrennen alle Bücher und ersetzen sie durch Googleausdrucke! Es kotzt mich wirklich an wenn in jedem Forum irgendwer dahergesch...en kommt und meint auf google verweisen zu müssen! Hast du für google einen Schrein zuhause eingerichtet - betest du täglich zu google!? Jetzt fehlt nur noch dass du sagst, mit Linux hätte man dieses Problem nicht! ...soviel kann ich garnicht fresse wie ich kotzen möchte wenn ich sowas lese!
@klugscheißer: Ich danke dir, besser hätte ich es auch nicht formulieren können! :-)
Hallo, das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das also kein Problem sein.
>>Es ist erschreckend, dass selbst in einem Elektronikforen solche >>Fragen gestellt werden. >Wo soll man sie sonst stellen? Google und eigenes Hirn benutzen hätte genügt und wäre schneller gegangen als hier eine Frage zu formulieren und die Antworten abzuwarten. Wenn in allen Foren die gleichen Fragen gestellt werden, weil die Fragesteller zu dumm oder zu faul zum denken sind, sind bald die meisten Foren nicht mehr lesbar, weil mit Müll zugemüllt. Es hat auch etwas mit gutem Benehmen zu tun, erst mal eine Suchmaschine und sein Hirn zu benutzen und sich erst mal selber zu bemühen bevor man ein Forum belästigt. Will man dann noch tiefer in Materie einsteigen und fragt spezielles, gibt es sicher niemand, der sich über die Fragestellung aufregt.
klugscheißer schrieb: > Es kotzt mich wirklich an wenn in jedem Forum irgendwer dahergesch...en > kommt und meint auf google verweisen zu müssen! Ich schlage vor, alle Fragen, die durch Google (oder eine andere Suchmaschine) in wenigen Sekunden beantwortet werden können, grundsätzlich nicht zu beantworten und den Thread schnellstmöglich zu löschen. Sowas Dummdreistes wie Dich hab ich echt lange nicht mehr erlebt.
Stefan Helmert schrieb: > das Defragmentieren verursacht doch nur einen einzigen Schreibzugriff je > Zelle. Bei 100.000-facher garantierter Wiederbescheibbarkeit sollte das > also kein Problem sein. Einem NTFS Defragger habe ich mal bei der Arbeit zugesehen. Während DOS/FAT Defragger am Filesystem vorbei optimierten und damit auch zusammenpackten, analysierte dieser NTFS Defragger lediglich die bestehende Fragmentierung der Files und kopierte zu sehr fragmentierte solange mit normalen Betriebssystemmechanismen in der Landschaft herum, bis entweder das Ziel oder eine Grenze erreicht war. Da NTFS bei vorneweg gegebener Filegrösse ganz gut alloziert funktioniert das leidlich. Aber nicht selten sind vor allem bei grossen Files etliche Anläufe drin. Dazu kommt, dass jede solche Aktion aus Konsistenzgründen synchron arbeiten muss. Alle Veränderungem am Filesystem, wie frei/belegte Blöcke, Filenodes, Dir-Einträge usw. werden ebenfalls mit jeder solchen Aktion geschrieben, manches pro Aktion mehrfach. Ohne TRIM Funktion führt das insbesondere bei Defragging von grossen Files (z.B. Disk-Images aus Virtualisierung) noch dazu, dass aus Sicht der SSD das Filesystem stärker belegt erscheint als es tatsächlich ist. Das Wear-Levelling also mehr Arbeit hat als nötig, denn der von der SSD als frei bekannte Bereich ist dafür sehr wichtig.
> Ich schlage vor, alle Fragen, die durch Google (oder eine andere > Suchmaschine) in wenigen Sekunden beantwortet werden können, > grundsätzlich nicht zu beantworten und den Thread schnellstmöglich zu > löschen. Das wäre mal ein guter Vorschlag. Im Hausfrauen- oder Technikanalphabetenforum könnte man obige Frage ja noch tolerieren. Aber doch nicht in einem Elektronikforum wo man einen gewissen mindest-IQ samt einigem technischen Basiswissen voraussetzen sollte.
Hallo, bisher nicht erwähnt: das wear levelling soll ja die Zugriffe gleichmässig über die ganze Kapazität verteilen, man kann also auch sagen, wear levelling fraktioniert absichtlich. Ein Defrag-Programm dagegen versucht alles am Anfang der Platte zu sammeln. Ich bin der Meinung, dass Defrag nicht nur wegen des Zugriffs ohne bewegliche Teile nichts nützt, sondern sogar massiv dadurch schadet, dass das wear levelling konterkariert wird. Gruss Reinhard
@ Reinhard Kern (Firma: RK elektronik GmbH) (rk-elektronik) >sagen, wear levelling fraktioniert absichtlich. Ein Defrag-Programm Fragmentiert. >dagegen versucht alles am Anfang der Platte zu sammeln. Ich bin der >Meinung, dass Defrag nicht nur wegen des Zugriffs ohne bewegliche Teile >nichts nützt, Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch langsamer. > sondern sogar massiv dadurch schadet, dass das wear >levelling konterkariert wird. Nun ja, das ist halt so ein legacy Problem. Die normale Software weiss nix von wear leveling und kann damit bisweilen ziemlich dazwischen funken. Ideal wäre ein von grund auf geschlossen entwickeltes Filesystem, welches direkt auf die speziellen Anforderungen von FLASH ausgelegt wäre. Ist aber aus Kompatibilitätsgründen so nicht machbar. Aber ich meine, die bestehenden Lösungen sind schon recht gut. Und sie werden besser. MfG Falk
Kleines wikipediazitat zum Thema gefällig: Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten nicht nötig. In Bezug auf die Schreibleistung differieren die Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten Core-Serie vor dem Defragmentieren,[35] während MTron für seine SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36]
> Kleines wikipediazitat zum Thema gefällig:
Wir können hier hoffentlich alle selber Wikipedia lesen!
Winfried J. schrieb: > Eine Defragmentierung ist aufgrund der marginalen Lese-Zugriffszeiten > nicht nötig. In Bezug auf die Schreibleistung differieren die > Herstellerangaben jedoch. So warnt OCZ die Nutzer seiner MLC-basierten > Core-Serie vor dem Defragmentieren,[35] während MTron für seine > SLC-basierten Produkte ein Defragmentieren sogar empfiehlt.[36] Das passt schon. Je nachdem was das Ziel der Defrag ist. Defrag nutzt ab, aber die Scheibleistung steigt. Da das Thema Abnutzung bei SLC Flash um den Faktor 10 weniger relevant ist lassen sich diese Aussagen mühelos in Einklang bringen.
Nebenbei bleibt noch die Frage der thermischen Punktbelastung bei Volllast, die wahrscheinlich sehr vom konkreten Aufbau abhängt.
Falk Brunner schrieb: > Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn > man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus > verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch > langsamer. Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die Adressierung zwischen den Blöcken geht keine Zeit verloren - es ist also egal, ob es der folgende Block ist oder einer am anderen Ende. Jedenfalls behaupte ich das jetzt mal so. Also Antworten bitte mit nachvollziehbarer Quellenangabe, sonst können Falk und ich ja würfeln. Gruss Reinhard
Reinhard Kern schrieb: > Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die > Adressierung zwischen den Blöcken geht keine Zeit verloren Das ist der Punkt wo ich mir nicht sicher bin. Es könnte schon einen Unterschied machen, ob für den gleichen Job einer oder 5 Blöcke angefasst werden müssen. Nur ist das verglichen mit einer Festplatte Klagen auf ziemlich hohem Niveau.
wobei eine definierte Größe der Datei auch eine definierte Anzahl an Blöcken belegt. wenn eine datei 1024 Bytes groß ist, und eine Zuodnungseinheit 256 Bytes hat, dann benötigt man eben 4 Speicheradresse. Ob die jetzt aufeinanderfolgen oder wild verteilt sind, spielt keine Rolle! - Beim LESEN!!! Beim schreiben sieht es anders aus: wenn die Adresse aufeinanderfolgend sind, reicht es eine Seite im Flash zu löschen, eine stark fragmentierte Platte dagegen müsste in obrigen Fall 4 Seiten Löschen bevor geschrieben werden kann - und ich denke hier wäre dann ein enormer Geschwindigkeitsverlust. So stelle ich mir das jedenfalls vor, korrigiert mich bitte wenn das nicht stimmt!
klugscheißer schrieb: > wenn eine datei 1024 Bytes groß ist, und eine Zuodnungseinheit 256 Bytes > hat, dann benötigt man eben 4 Speicheradresse. Ob die jetzt > aufeinanderfolgen oder wild verteilt sind, spielt keine Rolle! Die beiden Samsung SLC,MLC NAND-Flashes, deren Datasheet sich bei mir auf der Platte befinden, haben 2KB Blöcke. Intel SSDs verwenden 10 parallele Kanäle, was demzufolge auf einen effektive Pagegrösse von 20KB rausläuft. Wenn das Filesystem die üblichen 4KB Blöcke verwendet, dann macht es möglicherweise schon einen Unterschied, ob pro 20KB Lesevorgang 5 Flash-Pages beansprucht werden, oder nur eine. Dazu kommt, dass die SSDs den Flash-Speicher nicht direkt und linear adressieren können, weil das Wear-Levelling ein gewisses Mass an Verwaltung, an Blockmapping mit sich bringt. Je kleiner der einzelne Request, desto grösser ist der Verwaltungsaufwand. Das gleiche gilt insbesondere für das Betriebssystem, auch da ist neben der Transferrate die Anzahl Requests ein bedeutender Faktor in der I/O-Performance. Bei eher kleinen Requestgrössen (untere 2stellige KB) ist die Gesamtperformance erfahrungsgemäss hauptsächlich von der Anzahl Requests abhängig, weniger vom Datenvolumen. Folglich kann ein sequentieller Lesezugriff auf eine stark fragmentierte Datei durch die notwendige Verteilung auf etliche kleine Requests sehr wohl deutlich abgebremst werden.
Reinhard Kern schrieb: > Falk Brunner schrieb: >> Da wäre ich vorsichtig. Flash kann man auch nur dann SCHNELL lesen, wenn >> man große, zusammenhängende Blöcke auf eine Rutsch liest. Wenn man aus >> verschiedenen Adressen die Blöcke/Sektoren holen muss, wird er auch >> langsamer. > > Wer sagt das? Ein Block braucht seine Zeit, egal wo, und für die > Adressierung zwischen den Blöcken geht keine Zeit verloren - es ist also > egal, ob es der folgende Block ist oder einer am anderen Ende. > Jedenfalls behaupte ich das jetzt mal so. Also Antworten bitte mit > nachvollziehbarer Quellenangabe, sonst können Falk und ich ja würfeln. > > Gruss Reinhard Hängt vom verwendeten Flash ab und wie der Controller und der restliche Aufbau sind... Bsp.: Numonyx, Hynix oder Toshiba (die anderen Hersteller können ihren Kram behalten, wenn sie Datenblättern nur noch mit NDAs rausrücken) SLC large/medium http://hynix.com/datasheet/pdf/flash/HY27UK08BGFM%20(Rev0.0).pdf http://numonyx.com/Documents/Datasheets/NAND04G-B2D_NAND08G-BxC.pdf http://www.semicon.toshiba.co.jp/docs/datasheet/en/Memory/TC58NVG2S3ETA00_en_datasheet_090709.pdf Normaler Read: - Address setup / command : 7 Bytes a 25/50 ns - Busy (Datentransfer Speicher -> interner Cache): 25000 ns - Datentransfer zum Controller: n * 25/50 ns Cache-Read: - Address setup / Command : 7 Bytes a 25/50 ns - Busy: 25000 ns - Datentransfer erste Page zum Controller n * 25/50 ns - Busy: <3000 ns - 30000 ns - Datentransfer zweite Page ... Der Unterschied ist je nach Typ deutlich... Ähnliche Optimierungen gibt es auch beim Schreiben
Äääähhhhh, Leute..... Ich habe damals den Fred eröffnet (bin nun registrierter User) Ich habe doch bloß eine kleine simple Frage gestellt weil (es tut mir echt leid gefragt zu haben wenn ich sehe was hier abgeht.) Ich habe die Frage gestellt damit sich Menschen die (mit dieser neuen Technologie) mehr Erfahrung haben wie ich mir meine Frage beantworten da ich bisher verschiedene Statements gehört habe (Viele halt nur von vollpfosten die nur Compterbild und PCGH kennen). Es tut mir nochmals vielmals leid eine Frage gestellt zu haben, wusste nicht das das heutzutage unhöflich ist und sich Menschen die es nicht nötig haben zu antworten sich dadurch beleidigt/angegriffen fühlen. Ich werde es in Zukunft anstreben dumm zu sterben.....
wieso? ist doch jetzt eigentlich eine ganz sachliche und informative Diskussion!? das mit dem cache-read war mir jetzt auch neu!
>ist doch jetzt eigentlich eine ganz sachliche und informative >Diskussion!? Echt? K! Dann muss ich mich noch an den Umgangston hier gewöhnen ^^ Aber dann zieht euch warm an! :-)
> Jetzt fehlt nur noch dass du sagst, mit Linux hätte man dieses Problem > nicht! Gibt es bei Linux überhaupt Software zur Defragmentierung? Ich dachte, das macht dort der jeweilige Treiber für das Dateisystem selber.
Naja Linux verwendet ein anderes Dateisystem. In der regel ext2 oder ext3, neuerdings ext4. Ich habe mal gehört (das bedeutet das ich es nicht 100%ig sicher weiß) das diese dateisysteme für Fragmentierung nicht so anfällig sein sollen wie Fat, Fat32 oder NTFS. Berichtigt mich bitte wenn ich falsch liege.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.