55995
Oct 23, 2007, updated at Oct 24, 2007 (UTC)
26795
4
0
MFT defragmentieren?
Habe gerade etwas übers NTFS-Dateisystem gelesen und nun frage ich mich:
Ist es ratsam, die MFT zu defragmentieren?
Vielen Dank schonmal!
"Beim Formatieren der Festplatte wird für die MFT ein fester Platz reserviert, der nicht von anderen Dateien belegt werden kann. Wenn dieser voll ist, beginnt das Dateisystem freien Speicher vom Datenträger zu benutzen, wodurch es zu einer Fragmentierung der MFT kommen kann. Standardmäßig wird ein reservierter Bereich von 12,5 % der Partitionsgröße angenommen."
(wikipedia)
Ist es ratsam, die MFT zu defragmentieren?
Vielen Dank schonmal!
"Beim Formatieren der Festplatte wird für die MFT ein fester Platz reserviert, der nicht von anderen Dateien belegt werden kann. Wenn dieser voll ist, beginnt das Dateisystem freien Speicher vom Datenträger zu benutzen, wodurch es zu einer Fragmentierung der MFT kommen kann. Standardmäßig wird ein reservierter Bereich von 12,5 % der Partitionsgröße angenommen."
(wikipedia)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 71699
Url: https://administrator.de/contentid/71699
Printed on: April 19, 2024 at 18:04 o'clock
4 Comments
Latest comment
Die Frage ist natuerlich was du damit erreichen moechtest.
Moechtest du mehr Speicherplatz zur Verfuegung haben?
Dann erreichst du das mit der Defragmentierung des MFT nicht.
Moechtest du eine hohere Performance dann koennte man das schon erreichen wobei ich der Meinung bin das hier der Aufwand und das Risiko in keinem Verhaeltniss stehen. Die Gefahr ist immer dabei das die MFT beschaedigt wird und das macht dann keinen Spass mehr.
IMHO ist es nicht unbedingt ratsam die MFT zu defragmentieren.
Moechtest du mehr Speicherplatz zur Verfuegung haben?
Dann erreichst du das mit der Defragmentierung des MFT nicht.
Moechtest du eine hohere Performance dann koennte man das schon erreichen wobei ich der Meinung bin das hier der Aufwand und das Risiko in keinem Verhaeltniss stehen. Die Gefahr ist immer dabei das die MFT beschaedigt wird und das macht dann keinen Spass mehr.
IMHO ist es nicht unbedingt ratsam die MFT zu defragmentieren.
Moin farty!
Unterm Strich kommt auch bei mir als Antwort ein klares "Um Himmels willen NEIN!" heraus, aber mit einer etwas anderen Begründung.
Richtig, richtig, aber da gehören noch ein paar Hintergrundinfos dazu, sonst ist es missverständlich.
In der MFT, die M$-seitig standardmäßig mit ausliefert, ist unter anderem eine Restriktion (oder eine vorgesehene Datenfeld-Länge) hinterlegt, die eigentlich ein Relikt aus dem letzten Jahrtausend ist. Behaupteten vor ein paar Jahren zumindest viele Hilfsredakteure von PC-Zeitschriften. Nämlich die "feste Feldlänge" für Dateinamen und Pfadangaben, unter denen irgendwelche Datenklumpen abgelegt werden können. Die liegt so bei plusminus 250 Zeichen.
Länger darf kein "Pfad+Dateiname" werden, sonst lässt es sich nicht speichern.
Aber, so der damals erste und leider schwuppdiwupp umgesetzte Gedankengang:
"Das ist doch nicht nötig und ganz benutzerunfreundlich - der sehr verehrte DAU sollte doch die Möglichkeit bekommen, seine Pfade und Dateien zu benennen, wie er möchte. Auch mit 1000 Zeichen im Namen. Oder 10000 Zeichen. Dann braucht er sein raubkopiertes Video nicht "Stirb langsam 4.0" nennen, sondern kann auch noch dahinterschreiben, wo gezogen, einen Kurzabriss der Handlung und die Hauptdarsteller samt Autogrammadresse.
Lösung: Machen wir doch die Felder für "Pfad" und "Namen" in der MFT variabel breit...
Oder lieber eine feste Länge, aber variabel vom DAU einstellbar.
Na ja, und diese Softwareklitsche in Redmond hat auch gleich irgendwelche Praktikanten auf dieses Problem angesetzt und dieses Feature eingebaut. Die MFT kann jetzt vom DAU höchstselbst individualisiert werden - es lässt sich einstellen, dass "Pfad+Dateiname" bis zu 32767 Zeichen lang werden dürfen. Tolle Sache.
Es stellte sich allerdings schnell heraus, dass so gelegentlich eingesetzte Hilfsmittel wie der Explorer nicht wirklich gut einen Pfadnamen darstellen, der 20000 Zeichen lang ist, dass in der ganzen Rechteverwaltung leider ein define MAX_PATH 250 fest eingebrannt ist und dass sich zwar Dateien mit 254 Zeichen erzeugen, aber nur Dateien mit max. 251 Zeichen wieder lesen lassen usw. usw.
Seitdem ist dieses MFT-Thema nicht mehr so oft als Aufreisser auf den M$-Werbeplakaten mit dabei.
Achte mal drauf.
Aus diesen frühen Zeiten stammt jedenfalls auch diese Einstellung: "12,5% der Partitionsgröße werden für ... ( vereinfacht gesagt) physische Datei-Attribute vorgesehen".
Ist nicht verkehrt, wenn der Benutzer doch für jede 0-Byte-Datei, die irgendwo erzeugt wird, davon ausgehen muss, dass nochmal 32767 Zeichen für den Namen plus ein paar für sonstige Attribute verbraten werden.
Nach dem ganzen Prolog:
Hast Du die etwa umgestellt auf "ich will Dateinamen in der Länge von 35000 Zeichen eingeben können"????
Wenn Du das getan hättest, unterstelle ich mal, dann hätten wir Dich nicht in diesem Forum kennengelernt, weil Du Dir Sorgen um eine fragmentierte MFT machst...
Dann hättest Du von ganz anderen Effekten berichtet.
Also - mach Dir keine Sorgen. Du hast keine fragmentierte MFT.
Nix fragmentiert - nix dezufragmentieren.
Grüße
Biber
Unterm Strich kommt auch bei mir als Antwort ein klares "Um Himmels willen NEIN!" heraus, aber mit einer etwas anderen Begründung.
"Beim Formatieren der Festplatte wird für die MFT ein fester Platz reserviert, der nicht von anderen Dateien belegt werden kann. Wenn dieser voll ist, beginnt das Dateisystem freien Speicher vom Datenträger zu benutzen, wodurch es zu einer Fragmentierung der MFT kommen kann. Standardmäßig wird ein reservierter Bereich von 12,5 % der Partitionsgröße angenommen
Richtig, richtig, aber da gehören noch ein paar Hintergrundinfos dazu, sonst ist es missverständlich.
In der MFT, die M$-seitig standardmäßig mit ausliefert, ist unter anderem eine Restriktion (oder eine vorgesehene Datenfeld-Länge) hinterlegt, die eigentlich ein Relikt aus dem letzten Jahrtausend ist. Behaupteten vor ein paar Jahren zumindest viele Hilfsredakteure von PC-Zeitschriften. Nämlich die "feste Feldlänge" für Dateinamen und Pfadangaben, unter denen irgendwelche Datenklumpen abgelegt werden können. Die liegt so bei plusminus 250 Zeichen.
Länger darf kein "Pfad+Dateiname" werden, sonst lässt es sich nicht speichern.
Aber, so der damals erste und leider schwuppdiwupp umgesetzte Gedankengang:
"Das ist doch nicht nötig und ganz benutzerunfreundlich - der sehr verehrte DAU sollte doch die Möglichkeit bekommen, seine Pfade und Dateien zu benennen, wie er möchte. Auch mit 1000 Zeichen im Namen. Oder 10000 Zeichen. Dann braucht er sein raubkopiertes Video nicht "Stirb langsam 4.0" nennen, sondern kann auch noch dahinterschreiben, wo gezogen, einen Kurzabriss der Handlung und die Hauptdarsteller samt Autogrammadresse.
Lösung: Machen wir doch die Felder für "Pfad" und "Namen" in der MFT variabel breit...
Oder lieber eine feste Länge, aber variabel vom DAU einstellbar.
Na ja, und diese Softwareklitsche in Redmond hat auch gleich irgendwelche Praktikanten auf dieses Problem angesetzt und dieses Feature eingebaut. Die MFT kann jetzt vom DAU höchstselbst individualisiert werden - es lässt sich einstellen, dass "Pfad+Dateiname" bis zu 32767 Zeichen lang werden dürfen. Tolle Sache.
Es stellte sich allerdings schnell heraus, dass so gelegentlich eingesetzte Hilfsmittel wie der Explorer nicht wirklich gut einen Pfadnamen darstellen, der 20000 Zeichen lang ist, dass in der ganzen Rechteverwaltung leider ein define MAX_PATH 250 fest eingebrannt ist und dass sich zwar Dateien mit 254 Zeichen erzeugen, aber nur Dateien mit max. 251 Zeichen wieder lesen lassen usw. usw.
Seitdem ist dieses MFT-Thema nicht mehr so oft als Aufreisser auf den M$-Werbeplakaten mit dabei.
Achte mal drauf.
Aus diesen frühen Zeiten stammt jedenfalls auch diese Einstellung: "12,5% der Partitionsgröße werden für ... ( vereinfacht gesagt) physische Datei-Attribute vorgesehen".
Ist nicht verkehrt, wenn der Benutzer doch für jede 0-Byte-Datei, die irgendwo erzeugt wird, davon ausgehen muss, dass nochmal 32767 Zeichen für den Namen plus ein paar für sonstige Attribute verbraten werden.
Nach dem ganzen Prolog:
Ist es ratsam, die MFT zu defragmentieren?
Ja, wieso denkst Du denn, dass Deine MFT fragmentiert sein könnte???Hast Du die etwa umgestellt auf "ich will Dateinamen in der Länge von 35000 Zeichen eingeben können"????
Wenn Du das getan hättest, unterstelle ich mal, dann hätten wir Dich nicht in diesem Forum kennengelernt, weil Du Dir Sorgen um eine fragmentierte MFT machst...
Dann hättest Du von ganz anderen Effekten berichtet.
Also - mach Dir keine Sorgen. Du hast keine fragmentierte MFT.
Nix fragmentiert - nix dezufragmentieren.
Grüße
Biber
@Biber
Du hast ja eine klasse schreibe... das hat mir gerade meinen Abend versüßt
Allerdings muss ich da noch mal nachhaken denn ich habe da ein bisschen Verständissprobleme.
Ich kann leider keinen kausalen Zusammenhang zwischen der erlaubten Zeichenlänge einer Datei und einer möglichen oder auch nicht möglichen Fragmentierung der MFT sehen.
Es ist sehr wohl möglich das die MFT fragmentiert ist auch wenn man nur mit der Standardlänge (die ja nun auch wirklich ausreichend ist) arbeitet.
Bei NTFS werden als default 12,5 % reserviert für die MFT. Da werden also keine anderen Daten reingeschrieben und damit sollte es erstmal keine Fragmentierung der MFT geben.
Allerding wird jetz vom NTFS zwischen wenigen großen Dateien unterschieden und vielen kleinen Dateien.
Bei wenigen großen Dateien wird erst der freier Speicher verwendet. Nichts wird in den Bereich der MFT (MFT Zone) geschrieben. Bei den vielen kleinen Dateien verhält sich das allerdings anders, da wird in diese Zone geschrieben und damit wird eine Fragmentation des MFTs möglich. Aussderm nimmt auch die Größe der MFT zu da sehr kleine Dateien direkt in die MFT gespeichert werden.
Du hast ja eine klasse schreibe... das hat mir gerade meinen Abend versüßt
Allerdings muss ich da noch mal nachhaken denn ich habe da ein bisschen Verständissprobleme.
Ich kann leider keinen kausalen Zusammenhang zwischen der erlaubten Zeichenlänge einer Datei und einer möglichen oder auch nicht möglichen Fragmentierung der MFT sehen.
Es ist sehr wohl möglich das die MFT fragmentiert ist auch wenn man nur mit der Standardlänge (die ja nun auch wirklich ausreichend ist) arbeitet.
Bei NTFS werden als default 12,5 % reserviert für die MFT. Da werden also keine anderen Daten reingeschrieben und damit sollte es erstmal keine Fragmentierung der MFT geben.
Allerding wird jetz vom NTFS zwischen wenigen großen Dateien unterschieden und vielen kleinen Dateien.
Bei wenigen großen Dateien wird erst der freier Speicher verwendet. Nichts wird in den Bereich der MFT (MFT Zone) geschrieben. Bei den vielen kleinen Dateien verhält sich das allerdings anders, da wird in diese Zone geschrieben und damit wird eine Fragmentation des MFTs möglich. Aussderm nimmt auch die Größe der MFT zu da sehr kleine Dateien direkt in die MFT gespeichert werden.
Moin Gagarin,
für mich besteht schon ein kausaler Zusammenhang zwischen
a) der starr definierten Struktur
->laut dokumentiertem Algorithmus: nimm 12,5% einer Partitionsgröße, teile das durch (Const Pfad-Dateinamenslänge 30000 plus x Byte sonstige Dateiinfos + y Byte für Spur/Sector/Clustergelumpe) ....dann weißt Du, wie viele Einzel-Dateien Du da verwalten kannst.... und
b) dem Zeitpunkt, wo keine weitere Datei in diese nicht aufblasbare Tabelle hineinpasst.
Die für mich neue Information Bei den vielen kleinen Dateien verhält sich das allerdings anders, da wird in diese Zone geschrieben ist nur ein weiteres Indiz dafür, dass sich ein derartiges Betriebssystem nur dadurch verbreiten lässt, dass eben kein neu gekauftes Notebook/kein neuer Tower OHNE dieses bei MediaMarkt oder Saturn verramscht wird.
Eine bewusste Kaufentscheidung für so etwas kann doch mit hoher Wahrscheinlichkeit ausgeschlossen werden.
Egal - ich bleibe bei meinem "Um Himmels willen: NEIN!" von oben.
Abgesehen davon: mir ist so, als hätte ich neulich auf der Unfallchirurgie auch so etwas aufgeschnappt wie "Schwester, wo liegt die fragmentierte MFT?"
Kann aber auch sein, dass ich da was durcheinanderbringe.
Grüße
Biber
für mich besteht schon ein kausaler Zusammenhang zwischen
a) der starr definierten Struktur
->laut dokumentiertem Algorithmus: nimm 12,5% einer Partitionsgröße, teile das durch (Const Pfad-Dateinamenslänge 30000 plus x Byte sonstige Dateiinfos + y Byte für Spur/Sector/Clustergelumpe) ....dann weißt Du, wie viele Einzel-Dateien Du da verwalten kannst.... und
b) dem Zeitpunkt, wo keine weitere Datei in diese nicht aufblasbare Tabelle hineinpasst.
Die für mich neue Information Bei den vielen kleinen Dateien verhält sich das allerdings anders, da wird in diese Zone geschrieben ist nur ein weiteres Indiz dafür, dass sich ein derartiges Betriebssystem nur dadurch verbreiten lässt, dass eben kein neu gekauftes Notebook/kein neuer Tower OHNE dieses bei MediaMarkt oder Saturn verramscht wird.
Eine bewusste Kaufentscheidung für so etwas kann doch mit hoher Wahrscheinlichkeit ausgeschlossen werden.
Egal - ich bleibe bei meinem "Um Himmels willen: NEIN!" von oben.
Abgesehen davon: mir ist so, als hätte ich neulich auf der Unfallchirurgie auch so etwas aufgeschnappt wie "Schwester, wo liegt die fragmentierte MFT?"
Kann aber auch sein, dass ich da was durcheinanderbringe.
Grüße
Biber
