O&o Defrag Frage zu den Methoden
#46
geschrieben 20. September 2006 - 23:02
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
Anzeige
#47
geschrieben 21. September 2006 - 06:26
Zitat (Rika: 05.09.2006, 21:22)
Ja ne Rika: Wenn du eine Datei (jetzt mal normal ohne irgentwelche Defragmentierer) Kopierst und schaltest einfach den Rechner aus (stecker ziehen o.ä.) ist es klar, dass du Datenverlust hast Das ist ne Sache, die kannst du nicht einfach einem Defragmentierer zuschreiben
Zitat (bartek2k: 05.09.2006, 10:27)
Klingt aber irgendwie trotzdem logisch
Die NAME Methode eignet sich zum Beispiel direkt nach der Installation (da ua noch nicht allzuviele Prefretch (serschlagt mcih wenns falsch geschrieben ist) Dateien angelegt wurden, bzw nach dem Leeren des entsprechenden Ordners im %windir% sowie nach dem löschen der ROT13 Einträge in der Registry.
#48
geschrieben 21. September 2006 - 07:15
Zitat
Blödsinn. Die Originaldatei sollte ja noch einwandfrei vorhanden sein, was noch wichtiger ist, das Dateisystem sollte konsistent sein. Beim Defragmentieren wird auch erst ein neuer Cluster belegt, eine Kopie des Clusters dorthin erstellt und dann der Eintrag umgebogen. Das Problem ist, daß du ersteres und letzterer lieber nicht ohne vorherigen Anmeldung machen solltest, denn wenn's da zwischendrin abbricht, hast du mindestens ein Konsistentproblem bzw. im letzteren Falle auch Datenverlust. Und eben weil O&O Defrag nicht ordentlich mit FSCTL_MOVE_FILE arbeitet, kann es passieren, daß zwischen der Abfrage "Ist der Cluster frei? bzw. gib mir 'nen freien Cluster" und dem Alloziieren des Cluster die Gefahr besteht, daß der Cluster anderwaltig belegt wird - und wird dann überschrieben.
Zitat
Nochmal: Sie eignet sich nirgends, weil sich das Dateisystem intern eh nicht für die Dateinamen interessiert. Ein Ordner ist eine Liste von Dateien mit numerischer Kennung und Typ, und der Name wird ermittelt, indem man die numerische Kennung in der MFT nachschaut. Ich wüßte nicht mal, wie man unter diesen Aspekt eine Sortierung sinnvoll definieren soll, geschweige dann daß eine solche Sortierung irgendeinen Effekt hätte.
Zitat
Also wenn schon, dann solltest du Ironie deutlicher kennzeichnen.
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
#49
geschrieben 21. September 2006 - 08:51
#50
geschrieben 21. September 2006 - 08:56
ist es nicht so das eine partition wie ein buch ist?
ein buch besteht aus kapiteln (verzeichnisse) die wiederum in absätze (unterverzeichnisse) aufgeteilt sind!
der eigentliche inhalt spiegelt natürlich die datein wieder!
je nach verwendungszweck des buches ist eine sortierung nach namen doch höchst sinvoll!
denn die sortierungsmethode sortiert die kapitel mit allen absätzen und den kompletten inhalt dieser in alphabetischer reinfolge! so ist es ja auch sinvoll, ich möchte kein buch haben wo die kapitel durcheinander gewirbelt sind und ich um es sinvoll zulesen erstmal von seite 35 auf seite 57 blättern muß und dann gehts bei seite 12 weiter.
ob gefragte methode nun bei jeder partition sinvoll ist weiß ich nicht, aber zumindest scheint sie mir bei einer z.b. musik-partition mehr als sinvoll! dann kann man getrost einen kompletten ordner (kapitel) kopieren, entfernen oder abspielen und die festplatte hat keinen erhöten aufwand, da betroffene daten hintereinander weg kommen.
sollte ich da was falsch verstanden haben bitte ich um ausführliche berichtigung!
zu der eigentlichen arbeitsweise von O&O kann ich nichts sagen, habe aber bisher auch noch nie irgendwelsche probleme gehabt!
@rika die antwort auf sandokans frage würde mich auch interessieren!
Rika sagte:
und das aus deinen mund, das verwundert mich doch jetzt sehr! <- ich denke du weißt worauf sich das bezieht, nimms mir nicht übel!
#51
geschrieben 21. September 2006 - 09:32
Zitat
Nenn mich dumm, aber ich kenne keinen Ort in der Registry, wo Windows ROT13-kodierte Strings speichert oder wozu das gut sein sollte, geschweige daß irgendein Zusammenhang mit Dateisystemfragmentierung vorhanden wäre.
Zitat
Nochmal: Es interessiert sich einen Scheibendreck für Namen, und nachschlagen, wo ein Kapitel ist, musst du sowieso.
Bei mir liegen im Hauptverzeichnis der Bootpartition die Dateien boot.ini, ntldr, cmldr, ntdetect.com und die Ordner "cmdcons" und "System Volume Information" sowie die versteckten MFT*-Einträge. Sie haben die IDs 7, 11, 1189, 12, 43 und 89. Im normalen Bootvorgang wird zuerst ntldr, dann boot.ini, ntdetect.com und der Rest gar nicht geladen. Eine Hinternanderordnung gemäß Namen ist da absolut sinnfrei, ebenso wie eine Sortierung nach IDs. Wie auch in so ziemlich jedem anderen Szenario.
Zitat
Und dann fügt man eine Datei hinzu, die liegt dann widerum total woanders, und das Umsortieren erfordert dann wieder riesigen Aufwand. Sortierung nach letzterer Modifikation ist da ein wesentlich sinnvolleres Kriterium, da es die Änderungsvorgänge auf den Medium wiederspiegelt. Selten bis nie veränderte Dateien können zusammenhängend rumliegen, während sich oft änderne Dateien eher am Ende des Mediums und relativ frei voneinander sein sollten.
Zitat
Bei ordentlichen Defragmentierungsprogrammen, die ordentlich das NT Fragmentation API nutzen, kann nix schiefgehen, weil es Konsistenz und Transaktionssicherheit garantiert. Also warum die Datensicherheit sinnlos gefährden? Sehe ich nicht ein, zumal es wesentlich bessere Programme gibt, die es auch richtig machen.
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
#52
geschrieben 21. September 2006 - 11:40
Zitat
im übrigen nutze ich seit geraumer zeit nurnoch die windowsinterne defragmentierung und das geht auch ganz gut! da ja wie du schon sagst eh immer erst nachgeschaut wird wo betreffende datei sich befindet.
eigentlich müßte die art der defragmentierung je nach anwendungszweck variieren.
Dieser Beitrag wurde von Master.Max bearbeitet: 21. September 2006 - 12:03
#53
geschrieben 21. September 2006 - 11:52
Master.Max sagte:
Wenn du die Musik stets nur alphabetisch hörst, naja. Bei Shuffle-Wiedergabe nicht. Und spürbar ist der Geschwindigkeitsunterschied sowieso nicht.
For Emails always use OpenPGP. My KeyID: 0xA1E011A4
#54
geschrieben 21. September 2006 - 12:01
aber bei namen hätte man dann den vorteil wenn man sie nacheinander abspielt, oder halt ein kompletten ordner auf seinen portablen player überspielt. das man den geschwindigkeitsvorteil, egal wie man defragmentiert, wirklich wahr nimmt ist ja auch nicht gerade der fall!
ich plädiere für freie wahl zur defragmentierungsmethode!
#55
geschrieben 21. September 2006 - 12:04
Zitat
Und bei Sortierung nach letzter Änderung verursacht es eine geringere Fragmentierung, weil es ohnehin in einem Bereich liegt, der relativ unsortiert ist.
Zitat
Warum? 'Ne typische Festplatte schafft über 100 Head-Seeks pro Sekunde, da ist es vollkommen ausreichend, wenn nur die Dateien zusammenhängend sind und einer zukünftige Fragmentierung vorgebeugt wird, indem man keine Lücken dazwischen lässt. Die Anordnung der Dateien innerhalb einer Kategorie ist da ziemlich belanglos, denn die Head-Seeks sind halt billig und durchgehenden Lesen ganzer Dateigruppen ist auch ziemlich unrealistisch, insbesondere weil auch Ordner meist wo ganz anders liegen (und liegen sollten).
Zitat
Optimierung auf Anwendungsszenarien lohnt sich nur, wenn diese ganz spezifisch sind, wie z.B. ein immer gleicher Bootvorgang - das ist dann das, was der Prefetch-Mechanismus mit der layout.ini macht.
Zitat
Ja, wenn die Festplatte deutlich langsamer als die Übertragung wäre und sonst absolut nix im Dateisystem passieren würde. Sehr realistisch.
Dieser Beitrag wurde von Rika bearbeitet: 21. September 2006 - 12:06
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)
#56
geschrieben 21. September 2006 - 12:15
Zitat (Rika: 21.09.2006, 10:32)
Ja ich hab dich auch lieb
Mom sinds recht wenige Einträge (normalerweise sind da bis zu 100 Einträge und mehr drin). Aber die lösche ich ca 1-2 mal pro Monat. Erkennbar sind diese eigentlich an den "HRZR" am beginn des schlüssels.
Hier speichert Windows nochmal alles was wann wo ausgeführt wurde. Deswegen ist nach dem Löschen eigentlich auch die "Modified" bzw "accres" Methode nicht sonderlich effektiv.
Das dumme ist aber wenn man se nciht löscht, wächst diese Liste und müllt eigentlich sinnloser weise die Registry zu. Denn was interessierts mich was ich am 13.12.2004 aufgerufen habe?
Dieser Beitrag wurde von Stefan_der_held bearbeitet: 21. September 2006 - 12:16
#57
geschrieben 21. September 2006 - 12:16
Zitat
Zitat
#58
geschrieben 21. September 2006 - 12:18
Wenn du defragmentierst (egal wie) und du löscht ein Programm oder eine Datei läufst du immer bei NTFS und anderen MS- Fat's gefahr, Lücken in den Speicher zu reißen.
#60
geschrieben 21. September 2006 - 12:28
Zitat
Das hat aber nix mit ROT13 zu tun. Vielleicht ist "Rot" als Attribut und 13 als Zähler gemeint, aber selbst das ergibt wenig Sinn.
Zitat
Die Registry gilt quasi permanent als Modified und ist im laufenden Betrieb meist sowieso gelockt, wird also wohl kaum beim Defragmentieren Beachtung finden. Sie neigt aber auch nicht zur Fragmentierung.
Zitat
Mal ganz davon abgesehen, daß ich nicht erkennen kann, wo denn die Liste überhaupt zu finden ist, würde ich mal sagen, daß die in der benutzerspezifischen Registry liegt und damit kaum das System zumüllt. Und zur Fragmentierung führt das auch nicht, denn sie ist viel zu klein, und die Registry ist als leicht balancierte Hash-Tabelle von B+-Baum-Blöcken organisiert, wächst also nur sehr langsam (und zwar immer nur auf 2er-Potenzen bzw. eventuelle mit halben Zwischenergebnissen).
Zitat
Eher: gar keine.
Zitat
Richtig. Defragmentierungsprogramme können nicht weissagen, daß du vielleicht nach 'nem Jahr ein Programm wieder löschst und damit in der Kategorie der selten ändernenden Dateien dann eine Lücke auftritt. Das Ergebnis ist allerdings progessiv, d.h. die zu erwartende Fragmentierung und der Aufwand zur Defragmentierung ist minimal und das Ergebnis nährt sich zunehmend dem theoretischen Weissager-Optimum an. Die erste Fragmentierung dauert vielleicht noch lange, die späteren werden immer kürzer und irgendwann defragmentiert man eigentlich nur noch die letzten paar minimalen Änderungen.
Das ist im Prinzip auch die Funktionsweise der Defragmentierung noch letztere Änderung: Vorbeugen gegenüber zukünftiger Fragmentierung, statt sinnlose Perfektionierung nach irrelevanten Kriterien, die in Zukunft eher zu höherer Fragmentierung führen.
Ja, mata ne!
(For sending email please use OpenPGP encryption and signing. KeyID: 0xA0E28D18)