[eMule-Web]

[eMule-Web] (http://www.emule-web.de/board/)
-   Hard- und Software Allgemein (http://www.emule-web.de/board/hard-und-software-allgemein/)
-   -   MFT (Master File Table) riesig groß. (http://www.emule-web.de/board/12148-mft-master-file-table-riesig.html)

Noozle 26. February 2007 23:07

MFT (Master File Table) riesig groß.
 
Hi Leute.
ich hab ne 200 GB S-ATA HD in 4 Partionen aufgeteilt. C (15GB): nur WindowsXP und 3GB Auslagerungsdatei. D (40GB): alle laufenden Programme (Anwendungen und Games). E (60GB): Emule DLs und Emule Temp(Share) und temporer gespeicherte Datein. F(80GB): alles was Archiviert wird.
Folgendes Prob. Das system ist jetzt ca 4 Wochen installiert und mir ist jetzt aufgefallen das ein ziemlich großer Teil des Laufwerks D einfach nicht genutzt wird. Da ich immer nachdem ich ein Programm installiere sofort defragmetiere ist meine HD eigentlich ziemlich aufgeräumt. Alles Blau und ganz links nah beieinander(wenn nicht gar ein Block). als ich die ersten Programme installierte (alles was man täglich braucht:Nero ,WinRar, Adaware, Virenscanner...) klappte das auch hervorragend, aber als ich das erste Spiel (Battlefield 2142) installierte wars dann vorbei. da war auf eimal eine Lücke von ca 5GB und danach kam dann das Game und alle anderen Progs die ich danach installierte (alles sauber defragmentiert). Jetzt hab ich mir OO Defrag gekauft und der sagt mir das das "Für MFT Reservierter" Speicherplatz ist. OK. Gegooglet und rausgefunden was das ist aber die Größe auf D find ich unnormal. Es sind genau 4,8 GB (12%) aber warum nur aud Laufwerk D. Auf den anderen Partitionen hab ich auch MFT Blöcke gefunden, C hat 1054 Cluster, E hat 6177 Cl., F hat 12870 Cl. und D !!! ca.1377000 CL.
Das hatte ich noch nie. Kann man das irgendwie weg kriegen ???

Gruß .... Noozle.

Matrix1717 27. February 2007 15:43

Vermutlich nicht durch einen manuellen Eingriff.
Die MFT kann auch kleine Daten und Ordner speichern, das könnte die Ursache für die Größe sein. Außerdem reserviert Win automatisch einen größeren Bereich auf der HDD, um eine etwaige Fragmentierung so lange wie möglich zu verhindern. Sobald Win fesstellt das der Speicherplatz auf dem Laufwerk eng wird, versucht es ungenutzte Speicherbereiche in der MFT freizuräumen.

Noozle 27. February 2007 16:03

@ Matrix1717.
Genau so ähnliches hab ich auch beim Googlen gefunden. Also auch das es 12% der HD bzw Partion sein soll (???nur aber auf D und nicht auf den anderen Partionen???)und das die MFT auch nicht defragmentierbar sei (oo und diskeeper sollen angeblich auch das können). bei Laufwerk C ist jetzt die MFT sogar defragmentiert bei E + F nicht. Da sind es ca. 5 Blocks, davon 4 Rot und einer Gelb (reserviert). Bei D ist der erste Block (1377 cluster pro Block) und der letzte Grün (defragmentiert) alle anderen dazwischen (ca. 800 -900 Blöcke) sind reserviert.
Ich hatte zu Anfang die Auslagerungsdatei Mal ne Zeitlang auf D angelegt, da auf C die Auslagerungsdatei zum Fragmentieren neigt, da Windows immer nach dem defragmentieren selbstständig Datein wieder woanders anordnet und die Auslagerungsdatei dabei im Weg ist.
Vieleicht ist das ja ein Grund.

Matrix1717 27. February 2007 16:34

Zitat:

Zitat von Noozle
@ Matrix1717.
Genau so ähnliches hab ich auch beim Googlen gefunden.

Dann hättest Du dir deine Frage hier sparen können. :mrgreen:

Zitat:

Also auch das es 12% der HD bzw Partion sein soll (???nur aber auf D
Warum nicht? Die Unterschiede sind auf beiden Laufwerken vorhanden.

Zitat:

und nicht auf den anderen Partionen???)und das die MFT auch nicht defragmentierbar sei (oo und diskeeper sollen angeblich auch das können).
OO soll die MFT im Offline-Modus defragmentieren können. Zur Laufzeit ist der Zugriff wohlweißlich gesperrt.

Zitat:

bei Laufwerk C ist jetzt die MFT sogar defragmentiert bei E + F nicht. Da sind es ca. 5 Blocks, davon 4 Rot und einer Gelb (reserviert). Bei D ist der erste Block (1377 cluster pro Block) und der letzte Grün (defragmentiert) alle anderen dazwischen (ca. 800 -900 Blöcke) sind reserviert.
Trotz Offline-Defragmentation?

Zitat:

Ich hatte zu Anfang die Auslagerungsdatei Mal ne Zeitlang auf D angelegt, da auf C die Auslagerungsdatei zum Fragmentieren neigt, da Windows immer nach dem defragmentieren selbstständig Datein wieder woanders anordnet und die Auslagerungsdatei dabei im Weg ist.
Das dürfte am Prefetching liegen. Windows speichert Informationen ab welche Dateien am häufigsten geladen werden und ordnet sie auf die äußeren (da schnelleren) Spuren an; dadurch werden Ladezeiten verkürzt.

Zitat:

Vieleicht ist das ja ein Grund.
Du wirst vermutlich nie ein vollständig optimal defragmentiertes Windows bekommen. Achte einfach darauf, das die Fragmentation nicht überhand nimmt. Zum Defragmentieren gesperrter Dateien gibt es auch kostenlose Tools. Zum Beispiel für das Pagefile Pagedefrag. Das zeigt beim Starten an, welche gesperrten Dateien fragmentiert sind und kann auf Wunsch beim nächsten Neustart die Dateien an eine neue Position schreiben.

Seit vielen Monaten ist mir das zu blöd geworden auf die Fragmentation zu achten und vorher mein System von Datenmüll zu befreien. OO bietet die Möglichkeit an, definierte Jobs anzulegen und auch Kommandos vor und nach der Defragmentation auszuführen. Google mal nach cleanmgr.exe sagerun. Windows bringt die nötigen Mittel dafür mit.
Auf meinem System wird einmal die Woche C:\ von Müll befreit und im STEALTH-Modus Fragmente zusammengeführt. Vorher habe ich nach der NAME-Methode anordnen lassen, das ergab zwar ein schnelleres Booten, aber dafür musste das System immer lange defragmentieren.
Einmal die Woche vollautomatisch entmüllen und STEALTH dazu alle halbe Jahre SPACE reichen bei meiner Benutzung auch; geht schneller von statten und der Geschwindigkeitsverlust ist meiner Meinung nach verschmerzbar.

Aber jeder benutzt sein System anders, da wirst Du wohl eine adequate Methode für dich selbst finden müssen. :-)


Alle Zeitangaben in WEZ +1. Es ist jetzt 21:35 Uhr.

Powered by vBulletin® Version 3.8.3 (Deutsch)
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102