Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Mac 10.5.6 aufräumen

Mac 10.5.6 aufräumen

Jamiro7021.02.0913:17
Hallo,

ich bin ein relativ neuer user und habe das Gefühl, dass mein Mac immer langsamer wird.
Gibt es eine Möglichhkeit (Systemprogramm o.ä.) um den Mac mal aufzuräumen oder so was?

Vielen Dank für Eure Hilfe

Andreas
0

Kommentare

sierkb23.02.0922:34
Digitalo
Wenn die fragmentierten Daten die Verlangsamung verursachen müsste es eigentlich so sein.

Ich dachte bisher, MacOSX fragmentiere auf Dauer nicht bzw. ein Systemdienst defragmentiere im Hintergrund jedesmal fragmentierte Bereiche, wenn der Rechner sich gerade irgendwie im Idle-Modus befindet (er also nichts zu tun hat), sodass dauerhaft eigentlich keine fragmentierten Daten vorhanden sein dürften, sondern höchstens bis zur nächsten automatischen Aufräumaktion des Systems ...?

0
Digitalo
Digitalo23.02.0922:39
sierkb
Ich dachte bisher, MacOSX fragmentiere auf Dauer nicht ...
Ich habe mich auf den letzten Beitrag von DQ bezogen
DQ
sieht wohl so aus, angeblich fragmentiert die platte, stärker als gedacht…

Bis jetzt bin ich auch davon ausgegangen, dass defragmentierte Dateien unter OS X kein Thema seien.
0
DonQ
DonQ23.02.0922:50


andere schrieben bereits: nach langer zeit und beim schreiben und löschen von großen files oder störungen/hartem ausschalten, zb. kann es(relocate/aneinanderreihung) nötig sein, wie auch apple selber im support document schreibt(englisch):





„an apple a day, keeps the rats away…“
0
Digitalo
Digitalo23.02.0923:06
DQ
Danke für den Link.
Dass grosse Dateien fragmentiert werden können hatte ich noch vage im Gedächtnis. Was ich bis jetzt (auch in diesem Forum) darüber gelesen hatte liess immer den Schluss zu, dass dennoch kein Defragmentieren nötig sei.
0
DonQ
DonQ23.02.0923:18
so generell ist es auch nicht nötig, da apple wohl auf mehrere systeme hierbei zugreift, zusammenfassen kleiner dateien, cache, journaling…

die tools sind aber nicht so das wahre, beim defragmentieren…(was werde ich jetzt wieder prügel beziehen;) )

ausserdem tut eine schnelle platte auch ihr übriges, damit man das erst gar nicht merkt…

ob und was hier aber im argen liegt, systemerweiterungen, startobjekte én masse oder verwaiste server einträge, die andauernd aufgerufen werden aber natürlich keine antwort erhalten, erhalten können…fragmentierung…da ist gerade meine glaskugel überfordert.

hast du nicht ein systemupgrade(grafik, platte) durchgeführt, Digitalo ?

dann würde ich schlicht ein archive and install vorschlagen, erstmal…

die fragmentierung sollte damit auch behoben sein.

oder eben eine sicherung, aufspielung der sicherung.

„an apple a day, keeps the rats away…“
0
Digitalo
Digitalo23.02.0923:30
DQ
hast du nicht ein systemupgrade(grafik, platte) durchgeführt, Digitalo ?

Nein, habe ich nicht, aber aktuell auch kein Problem mit einer schleichenden HD. Das hat Jamiro70
Die Sache interessiert mich mehr generell... und wer weiss, wie die HD morgen tut?
0
sierkb23.02.0923:46
Digitalo
Was ich bis jetzt (auch in diesem Forum) darüber gelesen hatte liess immer den Schluss zu, dass dennoch kein Defragmentieren nötig sei.

Diese These ist wohl speziell von einer Person (...nerd) hier immer wieder hartnäckig vertreten bzw. verteidigt worden, wenn es darum ging, die Vorteile/Überlegenheit von MacOSX gegenüber anderen OS zu rühmen...

DQ:
die tools sind aber nicht so das wahre, beim defragmentieren…

Offenbar ist jene These nicht ganz so stabil und belastbar, wie man Glauben machen wollte -- wie allein die Existenz dieser beiden genannten Apple Dokumente beweist. Oder habe ich da jetzt was missverstanden?
0
DonQ
DonQ23.02.0923:55
sierkb

hat er es belegbar begründet ?

apple schreibt ja selbst: if you think you need to (defrag)

systems affected: bis 10.5.

desweiteren sollte die platte wohl zu 3/4 voll sein und fehler können erst recht beim benutzen der defrag tools auftreten, nicht nur(not only) bis zur verlangsamung des systems, sondern auch größere fehler, wie datenverluste, die wieder über eine rücksicherung behoben werden sollen.
„an apple a day, keeps the rats away…“
0
sierkb24.02.0900:02
DQ
hat er es belegbar begründet ?

Ich kann's Dir im Detail nicht mehr rekapitulieren. Du/ich müssten hier im Archiv wühlen bzw. die Suche bemühen, um das wieder alles hochzukramen. Ist auch schon 'ne Weile her. Will jetzt auch nix Falsches sagen oder das wieder aufrollen. Ich kann mich auch irren, was die Zuordnung zu einer bestimmten Person angeht...
0
Digitalo
Digitalo24.02.0900:03
sierkb
Diese These ist wohl speziell von einer Person (...nerd) hier immer wieder hartnäckig vertreten bzw. verteidigt worden...
Kann mich so nicht erinnern... scheint aber bei mir meinungsbildend gewirkt zu haben.

Wenn vor allem grosse Dateien betroffen sein können, müsste es ja genügen, den (die) User-Ordner auf eine externe HD und dann wieder zurück zu schieben. Wenn vorhanden, werden die grossen Files ja dort abgelegt sein.


0
Digitalo
Digitalo24.02.0900:06
DQ
... fehler können erst recht beim benutzen der defrag tools auftreten, nicht nur(not only) bis zur verlangsamung des systems, sondern auch größere fehler, wie datenverluste...
Genau solche Aussagen haben sich bei mir im Gedächtnis festgesetzt.

0
DonQ
DonQ24.02.0900:17
das steht so ausführlich im support document von apple.

natürlich habe ich auch gegenteiliges(vor allem auf das "defrag with little effort, wenig ergebniss) gehört und auch selber gesehen beim zurücksichern, zitiere:

die platte war völlig defragmentiert laut idefrag, jetzt rennt der mac wieder…allerdings nach einiger zeit: so ein müll, in zukunft sichere ich wieder zurück, dann brauche ich den schmarrn nicht und hab das gleiche ergebniss(frei aus dem gedächtniss)

„an apple a day, keeps the rats away…“
0
Digitalo
Digitalo24.02.0907:56
DQ
... in zukunft sichere ich wieder zurück, dann brauche ich den schmarrn nicht und hab das gleiche ergebniss(frei aus dem gedächtniss):-)
Versteh ich dich richtig: Dateien auf eine externe HD, danach wieder auf den Mac geschoben?

Falls ja, dann so?
Digitalo
Wenn vor allem grosse Dateien betroffen sein können, müsste es ja genügen, den (die) User-Ordner auf eine externe HD und dann wieder zurück zu schieben. Wenn vorhanden, werden die grossen Files ja dort abgelegt sein.



0
Vermeer
Vermeer24.02.0910:12
Defragmentieren ist unter OS X in der Regel nicht nötig. Ausnahme: wenn man sehr viel mit großen Dateien z.B. Videos arbeitet, vor allem dabei wenn die Festplatte ziemlich voll ist. In so einem Fall bringt defragmentieren tatsächlich einen Performancegewinn.

Defragmentieren geht so:
- Rechte reparieren
- Mit dem Festplattendienstprogramm die gesamte Platte auf eine externe Platte schieben. Prüfen, ob man von diesem Volume booten kann.
- Und das selbe Manöver wieder zurück
- wieder Rechte reparieren

Wenn dann dieses volle Programm und nicht nur die User-Daten hin und herschieben. Und vor allem dies natürlich nicht mit den Systemdaten machen. Ein so kopiertes Volume wäre nicht bootfähig.


Ein komplett bootfähiges Backup zu haben, ist ja ohnehin eine sinnvolle Sache. Wer zwei etwas gleichgroße und gleichgute Festplatten hat und an die leicht drankommt, kann sich das Zurückspielen auch sparen, indem er nach dem Spiegeln einfach die Festplatten tauscht.
0
Sirsalomon24.02.0910:29
Defragmentierung kann auch notwendig werden, wenn Bootcamp angeschubst wird.

Auch wenn OSX selbst den Hinweis gibt, dass dieser Umstand nur mit einem kompletten Backup and Restore behoben werden kann, werfe ich einfach mal das Programm iDefrag in den Raum...

Ob und in wie weit eine Defragmentirung beim OSX notwendig ist, will ich gar nicht erst hinterfragen, das könnte auch einen Glaubenskrieg auslösen...
0
Vermeer
Vermeer24.02.0910:37
Ich würde kein Deframentierungsprogramm verwenden. Wenn dabei etwas schief geht, hast Du ein dickes Problem. Beim HIn- und Herspielen hast Du immer auf einer Seite ein funktionierendes System und bist auf der sicheren Seite.
0
sierkb24.02.0911:36
Vermeer
Ich würde kein Deframentierungsprogramm verwenden. Wenn dabei etwas schief geht, hast Du ein dickes Problem.

Weshalb eigentlich? Ist beim Defragmentieren das Journaling denn nicht aktiv? Beim normalen Datei- und Datentransfer gilt ein Transfer doch erst als abgeschlossen, wenn das Dateisystem bzw. das Journaling diesen Vorgang als "abgeschlossen" betrachtet bzw. andernfalls wird der vorherige Zustand wieder hergestellt.
Wird beim Defragmentieren also das alles und auch das Journaling umgangen? Wird im Journal nicht vermerkt, welche Daten wohin verschoben/umorganisiert worden sind bzw. wird eine solche Umorganisation der Datenblöcke unterbrochen -- wirkt da das Journal nicht als Puffer zum Erhalt der Datenintegrität?

Was ist beim Defragmentieren anders, welche rolle spielt beim Defragmentieren das Journaling bzw. die Sicherung der Datenintegrität durch ebendiese im Gegensatz zum normalen Alltag, wenn das Gerät zum Beispiel während eines Datei-Transfers plötzlich stromlos wird oder eine Platte plötzlich ausfällt oder einfach unvorbereitet abgezogen wird (USB-/ Firewire HDDs)?
0
Vermeer
Vermeer24.02.0911:56
Das weiß ich nicht. Ich gehe einfach lieber auf Nummer sicher.
0
sierkb24.02.0912:15
Vermeer
Das weiß ich nicht. Ich gehe einfach lieber auf Nummer sicher.

Solange ich jedenfalls eine solche Antwort bekomme, habe ich keinen Anlass zu glauben, dass beim plötzlich unterbrochenen Defragmentieren irgendwas prinzipiell anders ist bzw. das Risiko höher sein soll als bei jedem anderen Datei-Transfer auch.

Und deshalb begegne ich solchen Stimmen, die einfach so behaupten, Defragmentierung auf dem Mac wäre im Zweifel sogar schädlich oder eine Gefahr für die Datenintengrität bzw. im Vergleich schädlicher oder risikobehafteter als jeder andere übliche Daten-Transfer, äußerst skeptisch. Belege für solche Äußerungen habe ich bisher noch nicht bekommen. Und solange ich die nicht habe, sind plötzliche Unterbrechungen eines Datei-Transfers in meinen Augen alle gleich schädlich bzw. gleich unschädlich -- egal, ob es sich dabei um einen normalen Datei-Transfer im Alltag handelt oder um den Vorgang der Defragmentierung, wo auf der Festplatte Daten-Blöcke hin- und hergeschoben werden. Plötzliche Unterbrechungen sind nie besonders gut und hilfreich. Und entweder das Journaling kann das abfangen, oder es kann das nicht abfangen. Ist das Journaling in dem einen Fall aktiv und in dem anderen Fall irgendwie nicht bzw. wird umgangen?

Behaupten und einfach so in die Welt setzen kann man viel, wenn der Tag lang ist vor allem dann, wenn bei Lichte betrachtet dahintersteckt, ein bestimmtes positives Bild/Image der Unantastbarkeit/Vorteilhaftigkeit von MacOSX hochhalten zu wollen...
0
Sirsalomon24.02.0912:32
Nur, um mal kurz etwas dazu zu schreiben.

iDefrag verwendet eine startfähige CD/DVD, die vom aktuellen System erstellt wird.

Da die zu defragmentierende Partition gemountet wird, wird auch das journaling aktiviert. Grundsätzlich ist aber folgendes dazu zu sagen.

Es ist in dem Zusammenhang schon richtig, dass ein Fremdprogramm durchaus Probleme bereiten kann, diese können aber auch im laufenden Betrieb auftauchen (unabhängig vom Programm).

Diese Unantastbarkeit vom OSX, die hier immer und immer wieder dargestellt wird, ist leider nicht gegeben. Ein System, dass nicht fragmentiert, gibt es derzeit noch nicht. spätestens, wenn mit sehr großen Dateien und mehreren Programmen gearbeitet wird, kommt das System nicht umher, eine Datei aufzuteilen. Ansonsten hätte Aperture (um nur ein Beispiel zu nennen) schon sehr bald riesen Probleme.

Wenn ein System nicht fragemntieren soll, muss eine Datei immer an einem Stück geschrieben werden. Bei meiner Aperture-Bibliothek wären das mit jedem neuen Bild mal eben 80 GB schreiben. Da das nicht geht, weil die Platte einfach nicht so groß ist, wird die Bibliothek eben auf die Blöcke aufgeteilt, die benötigt werden.

Und eben diese Aufteilung lässt ein System langsamer werden, da die Schreib-/Leselöpfe stets und ständig springen müssen und somit auch der Datenfluss unterbrochen ist. Ja, ich weis, es sind nur Millisekunden, aber summiert ist es eine ganze Weile. Zudem kommt auch noch hinzu, dass das System noch einiges mehr zutun hat, als sich nur um Aperture zu kümmern.

Ich defragmentiere jetzt aber auch nicht ein mal die Woche die Platte, sondern ehr sporadisch, dann aber vollständig (was dann schon einmal die ganze Nacht dauern kann). Ob ein spürbaren Geschwindigkeitzuwachs vorhanden ist, weiss ich nicht, aber Safari wird ja auch mit jedem Update schneller
0
Digitalo
Digitalo24.02.0913:27
sierkb
Ohne dass ich über konkret vorhandene oder nicht vorhandene Gefahren bei der Anwendung von Defragmentierungsprogrammen etwas weiss, das über das Hörensagen hinausgeht: Ist im Zweifelsfall das Hin- und Herkopieren der Daten nicht ganz einfach deswegen sicherer, weil im Fall einer Panne auf der einen HD die Originaldateien zugänglich bleiben. Erst wenn ich sicher bin, lösche ich die Files auf der 'Zwischenstation'
Vermeer
... Prüfen, ob man von diesem Volume booten kann...
Wenn dann dieses volle Programm und nicht nur die User-Daten hin und herschieben. Und vor allem dies natürlich nicht mit den Systemdaten machen.
.
Bin ich jetzt begriffstutzig? In das 'volle Programm' gehören doch auch die Systemdaten, sonst ist die Geschichte ja nicht bootfähig.
0
Vermeer
Vermeer24.02.0913:43
sierkb
Behaupten und einfach so in die Welt setzen kann man viel, wenn der Tag lang ist vor allem dann, wenn bei Lichte betrachtet dahintersteckt, ein bestimmtes positives Bild/Image der Unantastbarkeit/Vorteilhaftigkeit von MacOSX hochhalten zu wollen...

Aha, na dann.
0
Vermeer
Vermeer24.02.0913:50
Digitalo
Ist im Zweifelsfall das Hin- und Herkopieren der Daten nicht ganz einfach deswegen sicherer, weil im Fall einer Panne auf der einen HD die Originaldateien zugänglich bleiben. Erst wenn ich sicher bin, lösche ich die Files auf der 'Zwischenstation'

Genau.
Bin ich jetzt begriffstutzig? In das 'volle Programm' gehören doch auch die Systemdaten, sonst ist die Geschichte ja nicht bootfähig.
Ich meinte, wenn Du das System manuell auf eine externe Platte schiebst, ist sie nicht bootfähig. Es muss also mit dem Festplattendienstprogramm (oder einem anderen Tool) gemacht werden.
0
DonQ
DonQ24.02.0914:14
sierkb

von apple, speziell zu os9 und früher,

The defragmenting process generally results in a large amount of disk activity due to the amount of data being rearranged. Some disk defragmenting software packages also cannot completely recover if a critical portion of data on the hard disk should be in "transit" if the software fails. In this instance you may run the risk of losing that specific file, or all data on your hard drive.

daraus kann man schon schliessen, einige apps bekommen das schlicht nicht richtig hin und können es auch gar nicht richtig hinbekommen, da zb. bezüglich performance, apple alles was im start(boot) benötigt und geladen wird, absichtlich fragmentiert/in reihe auf die platte schreibt, wie apple hier schreibt: There is also a chance that one of the files placed in the "hot band" for rapid reads during system startup might be moved during defragmentation, which would decrease performance.

generell, bekommt das apple mit hfs+ und dem osx wohl schon recht gut hin.

wenn es allerdings immer perfekt und fehlerlos wäre, müsste sich auch niemand gedanken über zfs und sonstige verbesserungen machen und alle osx entwickler die sich damit befassen, wären arbeitslos


„an apple a day, keeps the rats away…“
0
sierkb24.02.0915:02
DQ
sierkb
von apple, speziell zu os9 und früher

Quelle? URL?

Du schreibst ja selber: speziell os9 und früher.
OSX hat bei HFS+ Journaling (in den ersten MacOSX Versionen war das wohl noch standardmäßig deaktiviert bzw. man musste es händisch aktivieren).
wenn es allerdings immer perfekt und fehlerlos wäre, müsste sich auch niemand gedanken über zfs und sonstige verbesserungen machen

Sehe ich auch so. HFS+ mit seinem Journaling ist weit davon entfernt, perfekt zu sein, das habe ich unlängst leidvoll am eigenen System spüren dürfen (in Kombination mit Spotlights gnadenlosen Indizierungs-Daemon wurde mein System zu 100% ausgelastet, ging völlig in die Knie, hatte noch nicht mal die Kraft, ein Terminal aufzurufen). Späteres Herumelaborieren ergab: Dateisystem bzw. Journaling zerschossen. Unrettbar. Bin da bis in die Tiefen von MacOSX bzw. HFS+ vorgedrungen und habe dann nach einer Woche intensiver Recherche und intensiver Bemühungen lesen dürfen: passiert. Wenn auch sehr selten, aber sowas passiert. Aus heiterem Himmel. Während des normalen, laufenden Betriebes, ohne besondere Aktivitäten. Einfach so. Kann vorkommen. Unter Linux ext2/ext3 ist mir sowas noch NIE vorgekommen! Und unter Windows' NTFS auch nicht!

HFS+ hat, wenn man es mal als weiterentwickeltes HFS, aber eben immer noch ein um Journaling und andere Dinge ergänztes alt ehrwürdiges HFS betrachtet, immerhin schon über 20 Jahre auf dem Buckel. Das merkt man, es ist zuweilen antiquiert und wird heutigen Anforderungen manchmal nur noch schlecht gerecht. Auch deshalb der von vielen herbeigesehnte Schritt zur Neuerung (vielleicht ein HFS++?) bzw. gleich sowas wie ZFS als Ablösung.
0
DonQ
DonQ24.02.0915:35
DQ








aus erstem link, das die apps platz brauchen-brauchen müssen beim aufräumen, defragmentieren ist ja eigentlich selbsterklärend, auch das es sich kaum geändert hat, kann man aus dem 2ten link schliessen.

das zfs sollte ja bereits unter leo oder sogar früher in der gui sein, aus gesprächen weis ich aber das die entwickler da ziemliche probleme hatten und es wohl wieder rausgenommen wurde aus den finals.

sowieso gab es da auch eine discussion zum 128bit auf heise, netopolis; was ja auch indirekt die richtung weist, imho.

jetzt wird mir aber das thema zu heiß und ich verabschiede mich erst mal.
„an apple a day, keeps the rats away…“
0
Digitalo
Digitalo25.02.0900:18
Vermeer
Ich meinte, wenn Du das System manuell auf eine externe Platte schiebst, ist sie nicht bootfähig. Es muss also mit dem Festplattendienstprogramm (oder einem anderen Tool) gemacht werden.
Hat sich geklärt.

Dass die HDs durch mechanische Alterungsprozesse langsamer werden... sind das subjektive Eindrücke oder ist dies Fakt?

0
Esäk
Esäk25.02.0901:25
Ist rein subjektiv, Digitalo.
Der Motor dreht sich immer gleich schnell
er wird von einer Regelung auf Drehzahl gehalten.

Zur Frage der Sicherheit:
Chrasht ein Defragmentierer , sind die grade bearbeiteten Daten immer futsch. Anzunehmen, dass hier das OS hilft ist ..., denn diese Software geht möglichst hardwarenah ran. Einfach deshalb schon ist das Umkopieren die prinzipiell sicherere Lösung, wenn auch bei nur geringer Fragmentierung langsamer.
„Die Todesstrafe gehört auch in Hessen abgeschafft!“
0
Digitalo
Digitalo25.02.0901:47
Esäk
Ist rein subjektiv, Digitalo.
Der Motor dreht sich immer gleich schnell
er wird von einer Regelung auf Drehzahl gehalten
Ich kann es mir aus verschiedenen Gründen ebenfalls nicht vorstellen, dass ein Alterungsprozess der Mechanik die Ursache für eine Verlangsamung sein kann. Dies aus verschiedenen Gründen - unter anderem auch aus dem von dir genannten.

Vermeer hat in zwei Beträgen (23.02.2009, 11:57 /21:23) sehr klar eine gegenteilige Aussage gemacht, die ich hier nochmals aufgreifen wollte in der Hoffnung, dass er sich noch dazu äussert.

0
Stefab
Stefab25.02.0905:23
Eines der Programme, die sich nahezu unlöschbar ins System einnistet ist das von Apple eigene Final Cut Studio. Haufenweise Pakete, Content irgendwo, alles mögliche im Application Support, in "Benutzer/Für alle Benutzer" kommt viel rein, diverse Plug-Ins, uvm. Weils mal nicht richtig funktioniert hat, hab ich da so viel Zeug aus so vielen Ordnern rausgesucht und gelöscht und danach gings nach ner Neuinstallation wieder (nur neu installieren war zu wenig). Bei Adobe CS3 ist wenigstens ein netter Uninstaller dabei. Naja, k.A. Apple geht vielleicht davon aus: Einmal Schnittrechner, immer Schnittrechner ansonsten wird eh neu aufgesetzt. Trifft wohl auch meistens zu. Aber dass gerade Apple mit so nem schlechten Beispiel vorangeht find ich nicht gut. 52 GB über die ganze HD verteilt.
Eine saubere Lösung wäre da eh auch endlich mal nicht schlecht. Wenn man mit Desinstaller einfach Pakete löscht, muss man auch wahnsinnig aufpassen, dass da nix dabei ist, was das System vielleicht noch braucht.
Am besten sind eigentlich die Apps, die alles in ihrem .app drin haben und wenn Ressourcen mit anderen Programmen geteilt werden sollen, dann eben Application Support (und dort deutlich erkennbare Zugehörigkeit). Aber es gibt leider viel zu viele Ausnahmen. Auch weiß man ja oft nicht. Programme können ja zB. auch gleich neue Fonts mit installieren. Will man die dann behalten, oder soll die auch weg? Oder Quicktime-Plug-Ins, Browser-Plug-Ins oder sonst was... alles ziemlich kompliziert.
Hab mir jetzt auch mal AppTrap gesaugt und gestartet: Beim Löschen von Onyx hat es nix gefragt. Auch ok. Das App weiß dann hoffentlich auch, was es tut, hab nix näheres darüber gelesen, ausser, wie man es benutzt.
Wenn jemand eine tolle und halbwegs einfache (nicht zeitaufwendige) Lösung hat, um (nahezu) allen Datenmüll loszuwerden: Nur raus damit!
0
Stefab
Stefab25.02.0905:50
PS: Wegen dem Defragmentierungszeug... kann man da nicht auch einfach Time-Machine Backups nehmen? Also HD löschen, OSX neu aufsetzten und das letzte Time-Machine Backup wieder einspielen, wenn man das Gefühl hat, die HD muss defragmentiert werden. Wenn ja, wie geht man da am besten vor? System von Disk installieren, alle Updates machen und gehts dann mit dem Migrationsassistenten weiter, oder irgendwie anders?

Und so nebenbei würde mich ein Tool interessieren, dass anzeigt, wie stark die Defragmentierung ist (am besten gratis, Defragmentieren muss es ja nicht können). Könnte bei mir schon relativ groß sein, dank Video und auch immer wieder Aufnahmen aus dem Fernsehen (MPEG2) und löschen dieser, etc. Dazu hat ja EyeTV nen ständigen Timeshift-Buffer mitlaufen (momentan auf 1800 MB eingestellt, stelle nach Bedarf um), und dazu sind meist nur so 20-40 GB frei. (von 266 der Rest auf 320 GB ist FAT32 mit WinXP und Bootcamp)
0
Vermeer
Vermeer25.02.0907:42
Digitalo: Das war mal das Ergebnis einer ausgiebigen Diskussion hier. Ich habe das damals geglaubt und in der Praxis beim Festplattentausch (sogar von einer 7200er auf eine 5400er) deutlich zu spüren bekommen. Nach diesem Thread hier habe ich aber Zweifel bekommen und auch nochmal recherchiert. Das scheint tatsächlich Blödsinn zu sein. Der Effekt damals war wahrscheinlich einfach nur das Ergebnis der mit der Überspielung erfolgten Defragmentierung. Jedenfalls war mein Rechner damals noch mit einer ziemlich kleinen Festplatte und diese mit vielen Videodateien meist bis ans Limit benutzt.

Jetzt wollte ich es wissen und habe seit langer Zeit mal wieder die Platte wie oben beschrieben defragmentiert, obwohl ich jetzt meine Rechner nicht besonders langsam fand. Das Ergebnis ist aber verblüffend. Der Rechner rennt auf einmal wie ein frisch gestriegeltes Eichhörnchen. Dass das eine Rolle spielt wußte ich schon, wie man ja oben lesen kann, aber ich hatte das halt nur ein paar Mal gemacht und zwar immer dann, wenn eine neue Platte fällig war. Und hatte dann den Effekt vor allem auf die neue Platte geschoben.
0
Vermeer
Vermeer25.02.0907:47
Stefab: das wäre mir aber zu aufwendig. Außerdem kann ich nur jedem empfehlen, zusätzlich zum Time-Machine-Backup immer ein vollständiges Backup auf einer weiteren Festplatte zu haben. Die Dinger kosten ja nicht viel. Eine Festplatte als Backup wäre mir zuwenig Sicherheit. Aber noch etwas spricht dafür: Meine Erfahrung ist, das man z.B. eine Festplattencrash grundsätzlich nur dann hat, wenn überhaupt keine Zeit für eine Reparatur ist. Und dann ist eine externe Platte, von der man booten kann einfach Gold wert.
0
macscout
macscout25.02.0909:56
(Das mit dem Backup ist ein Thema für sich. Meine Strategie sind zwei externe Platten, die beide so groß sind wie meine interne Platte (750 GB). Da mache ich wechselweise ein vollständiges Backup drauf, und nehme das aktuelle Backup mit in die Firma. Altes Backup raus, aktuelles Backup rein in die Schublade, und nun kann auch das Haus abbrennen, ein Backup habe ich noch)

Zum Defragmentieren: Ich würde den Weg über ein Backup (mit CCC) immer einer Defragmentier-Software vorziehen. Wenn beim Zurückspielen was schief geht, spiele ich es eben erneut zurück. Wenn beim Defragmentieren was schief geht, habe ich u.U. verloren. Ein Backup muss ich in jedem Fall machen.
Dazu muss ich aber auch sagen, dass ich noch die alten Norton-Utilities-Zeiten erlebt habe, und das prägt. Seit damals habe ich ein tief sitzendes Misstrauen gegenüber Defrag-Tools und allem, was auf meiner Platte Voodoo machen will. Das kann wohl nur ein Psychiater beheben
CCC und Apples Festplatten-Dienstprogramm, mehr kommt mir nicht ins Haus.
0
Digitalo
Digitalo25.02.0914:58
Vermeer
Digitalo: Das war mal das Ergebnis einer ausgiebigen Diskussion...
Danke für deine Rückmeldung!
Sie erspart mir das Umdenken... und eine neue HD.
Vermeer
- Mit dem Festplattendienstprogramm die gesamte Platte auf eine externe Platte schieben. Prüfen, ob man von diesem Volume booten kann.
ich will die heute Nachmittag noch durchführen. Mit dem Festplattendienstprogramm habe ich es noch nie gemacht.
Wo? 'Wiederherstellen?' Kommt mir etwas eigenartig vor.



0
macscout
macscout25.02.0915:36
Warum nicht den Carbon Copy Cloner nehmen? Kostenlos und zuverlässig.
0
Vermeer
Vermeer25.02.0922:15
Digitalo: genau, mit Wiederherstellen. Einfach das Festplattensymbol von Quelle und Ziel in die Felder zielen. Der Ausdruck Wiederherstellen ist tatsächlich etwas verwirrend. Wahrscheinlich einfach blöde übersetzt.
0
MacMark
MacMark26.02.0908:20
Jamiro70
... habe das Gefühl, dass mein Mac immer langsamer wird. Gibt es eine Möglichhkeit (Systemprogramm o.ä.) um den Mac mal aufzuräumen ...

Alles, was Du per Drag & Drop installieren kannst, ist prinzipiell harmlos, da es nicht im System landet.
Alles, was installiert werden muß und von einem Admin-User erlaubt werden muß, ist potentiell schädlich auf Systemebene.

Man kann herausfinden, was auf dem aktuellen System gerade los ist.

sudo launchctl list | grep -v com.apple > ~/Desktop/non_apple_launchd.txt
Die Textdatei non_apple_launchd.txt auf dem Desktop ist dann eine Liste der für root geladenen Aufgaben, die nicht den Apple-Stempel haben.

Interessant ist auch, wenn bei "kextstat" etwas auftaucht, was nicht com.apple.* heißt. Schnell rauszufinden mit
kextstat | grep -v com.apple >  ~/Desktop/non_apple_kexts.txt
Die non_apple_kexts.txt zeigt dann die geladenen Kernel-Erweiterungen an. Wenn da Drittsoftware auftaucht, ist deren Notwendigkeit zu prüfen.

Und dann kann man noch nachschauen, welche Prozesse so laufen:
ps -ax >  ~/Desktop/ps.txt
Die Liste liegt dann in der "ps.txt".

Dann non_apple_launchd.txt, non_apple_kexts.txt und ps.txt hier hochladen (am besten mit Code-Tags, damit es leserlich bleibt).
„@macmark_de“
0
MacMark
MacMark26.02.0910:19
sierkb
... Was ich bis jetzt (auch in diesem Forum) darüber gelesen hatte liess immer den Schluss zu, dass dennoch kein Defragmentieren nötig sei....

Das ist korrekt. Siehe auch, was ich hier dazu ausführe:
macmark.de/osx_auto-clean.php#defragmenting

Manuelle Defragmentierung birgt zudem das Risiko, den Platteninhalt komplett zu verlieren.
„@macmark_de“
0
DonQ
DonQ26.02.0910:27
MacMark

da solltest du mal mit der deutschen supportseite von apple verhandeln
von wegen lokalisierung und so…
„an apple a day, keeps the rats away…“
0
sierkb26.02.0910:44
MacMark
Das ist korrekt. Siehe auch, was ich hier dazu ausführe:
macmark.de/osx_auto-clean.php#defragmenting

Deine Ausführungen zum Thema kenne ich bereits. Ich habe Deine Essays vor längerem bereits schon gelesen, und ich schätze und achte sie auch. Sie sind im Großen und Ganzen sehr gut, lehr- und hilfreich. Deshalb habe ich sie auch hier bei MTN schon mehr als einmal zitiert oder habe drauf hingewiesen.
Allerdings muss man nicht in jedem einzelnen Punkt mit Dir bzw. Deinen Ausführungen/Interpretationen übereinstimmen.

Dein Sicht hierzu konkret mag für den Regelfall richtig sein. Generell gesehen bzw. Ausnahmefälle inbegriffen widersprechen Dir da mindestens aber die beiden hier schon genannten Apple Support Dokumente, welche ziemlich direkt ansprechen, dass Fragmentierung vorkommt und vorkommen kann, die nicht einfach so mit dem eigenen System-Daemon bzw. den eigenen System-Werkzeugen in den Griff zu bekommen ist und in einem solchen Fall dann auch externe Werkzeuge hilfreich und notwendig sein können, diese Fragmentierung dann aufzuheben. Neben dem schon hier wie auch in diesen Dokumenten beschriebenen Umkopieren/Backup/Zurückspielen als Möglichkeit, so ein Problem zu lösen.
Manuelle Defragmentierung birgt zudem das Risiko, den Platteninhalt komplett zu verlieren.

Ist das Journaling dabei eingeschaltet oder ausgeschaltet? Was unterscheidet das Defragmentieren in diesem Fall von unter anderen Umständen vorgenommenem (meinetwegen blockweise) Verschieben von Daten? Meines Wissens finden Defragmentierungsvorgänge ganz allgemein unter den verschiedenen Betriebssystemen ebenfalls unter verschärften Sicherheitsbedingungen statt -- grob gesagt: ein Datenblock wird erst vom Ursprungsort an den Zielort kopiert, und erst wenn die Kopie dieses Datenblocks am Zielort heil angekommen ist, dann erst wird das Original am Ursprungsort gelöscht, andernfalls wird der Vorgang als nicht stattgefunden betrachtet bzw. rückgängig gemacht. Oder habe ich da was falsch verstanden?
Die Frage, die sich da jetzt stellt ist die: wird das protokolliert? Wer protokolliert das? Läuft das Journaling bei sowas mit? Hast Du da Antworten drauf bzw. Hinweise auf andere Quellen, wo man's nachlesen kann? Ich glaube, ich schaue mir mal die technische Doku zu HFS+ in Apples Developer Dokumenten an, um eine Antwort drauf zu finden...
0
macdevil
macdevil26.02.0910:45
MacMark
Jamiro70
... habe das Gefühl, dass mein Mac immer langsamer wird. Gibt es eine Möglichhkeit (Systemprogramm o.ä.) um den Mac mal aufzuräumen ...

Alles, was Du per Drag & Drop installieren kannst, ist prinzipiell harmlos, da es nicht im System landet.
Alles, was installiert werden muß und von einem Admin-User erlaubt werden muß, ist potentiell schädlich auf Systemebene.

Man kann herausfinden, was auf dem aktuellen System gerade los ist.

sudo launchctl list | grep -v com.apple > ~/Desktop/non_apple_launchd.txt
Die Textdatei non_apple_launchd.txt auf dem Desktop ist dann eine Liste der für root geladenen Aufgaben, die nicht den Apple-Stempel haben.

Interessant ist auch, wenn bei "kextstat" etwas auftaucht, was nicht com.apple.* heißt. Schnell rauszufinden mit
kextstat | grep -v com.apple >  ~/Desktop/non_apple_kexts.txt
Die non_apple_kexts.txt zeigt dann die geladenen Kernel-Erweiterungen an. Wenn da Drittsoftware auftaucht, ist deren Notwendigkeit zu prüfen.

Und dann kann man noch nachschauen, welche Prozesse so laufen:
ps -ax >  ~/Desktop/ps.txt
Die Liste liegt dann in der "ps.txt".

Dann non_apple_launchd.txt, non_apple_kexts.txt und ps.txt hier hochladen (am besten mit Code-Tags, damit es leserlich bleibt).

Tolle Tipps. Werd ich heute abend gleich mal ausprobieren. Mich interessiert der Unterschied zwischen frisch installiertem MacBook Pro und dem iMac, welcher ein System hat, das ich seit 10.2 rumschleppe
„Wie poste ich richtig: Ich schreibe einfach überall irgendwas hin. Egal wie unnötig mein Post ist.“
0
MacMark
MacMark26.02.0912:33
sierkb
... Apple Support Dokumente, ... dass Fragmentierung ... vorkommen kann, die nicht einfach so mit dem eigenen System-Daemon bzw. den eigenen System-Werkzeugen in den Griff zu bekommen ist ...
Manchmal gelingt es beispielsweise nicht, daß der "Boot Camp Assistant" genug Platz am Stück freiräumen kann, um die Platte partitionieren zu können. In dem Fall hilft manuelle Defragmentierung.
sierkb
Ist das Journaling dabei eingeschaltet oder ausgeschaltet? Was unterscheidet das Defragmentieren in diesem Fall von unter anderen Umständen vorgenommenem (meinetwegen blockweise) Verschieben von Daten? ...
Das sind Fragen, die man dem jeweiligen Defrag-Tool-Anbieter stellen sollte
Bei Stromausfall, Fehler im Tool oder versehentlichem Neustart während der Defragmentierung ist der Platteninhalt ziemlich sicher verloren.
Wenn Du im Finder Daten verschiebst,riskierst Du nicht die ganze Platte.

„@macmark_de“
0
sierkb26.02.0913:13
MacMark
Manchmal gelingt es beispielsweise nicht, daß der "Boot Camp Assistant" genug Platz am Stück freiräumen kann, um die Platte partitionieren zu können. In dem Fall hilft manuelle Defragmentierung.

Zum Beispiel. Apple nennt in seinem Support-Dokument für MacOSX noch ein anderes Beispiel (im Zusammenhang mit dem evtl. Vorhandensein sehr großer Dateien und wenig freiem Platz auf der Festplatte), wo manuelle Defragmentierung hilfreich sein kann/könnte.

Das ist schon mal eine andere Grundaussage bzw. ein anderer Tenor als das, was Du da in Deinem Artikel schriftlich festgehalten hast, bzw. es zeigt durchaus auf, dass es gewisse Grenzen gibt, wo nicht-vorübergehende Fragmentierung tatsächlich zutage tritt, die nicht mit systemeigenen Mitteln behoben werden kann.
HFS+ bzw. die systemeigenen Tools sind zwar bemüht Fragmentierung zu vermeiden bzw. zurückzuführen, aber in Gänze und in jedem Fall ausschließen können sie etwaige zurückbleibende Fragmentierung offenbar nicht. Das kommt in Deinem betreffenden Essay nicht rüber. Es gibt also offenbar Ausnahmen der Regel -- Ausnahmen, die gar nicht mal so selten sein müssen und durchaus häufiger vorkommen können. Oder?
sierkb
Das sind Fragen, die man dem jeweiligen Defrag-Tool-Anbieter stellen sollte
Bei Stromausfall, Fehler im Tool oder versehentlichem Neustart während der Defragmentierung ist der Platteninhalt ziemlich sicher verloren.

Was ist bei einem plötzlichen Stromausfall oder versehentlichen Neustart, während ich bei ganz normalem Betrieb ein Programm/eine Datei verschiebe, denn offenbar gehen Verschiebungsaktionen ansonsten ja, z.B., wenn man ein Programm aus dem /Applications-Ordner nach /Applications/Utilities (oder umgekehrt) bewegt/zieht?

Sind die Risiken bei den Szenarien nicht eigentlich gleich?
Wenn Du im Finder Daten verschiebst, riskierst Du nicht die ganze Platte

Du meinst, deshalb bietet der Finder nur "Kopieren" an und nicht "Verschieben"? Sollte das der tiefere Grund dafür sein, dass der Finder dieses Feature nicht anbietet, das Windows anbietet, das verschiedene Linux-Desktops anbieten und das offenbar auch an anderen Stellen in MacOSX zu gehen scheint?
0
MacMark
MacMark26.02.0914:19
Wie lange bist Du schon am Mac? Der Finder zwangs-verschiebt Dateien mit gedrückter Command-Taste.

Die Risiken sind nicht gleich: Ganze Platte weg (Defragmentierungstool) ungleich eine Datei weg (Finder-Move).

Die Art der Fragmentierung, die beim Partitionieren stören kann, ist für alles andere in der täglichen Arbeit vollkommen unerheblich.
OS X verhindert die Fragmentierung, die zu Geschwindigkeitseinbußen führen kann. Beim Partitionieren stört jedoch nicht, daß einzelne Dateien eventuell fragmentiert wären, sondern daß nicht abnorm viel freier Speicher am Stück vorliegt, aus dem man eine zusammenhängende Partition erstellen könnte.

Mein Artikel behandelt Performance-relevante Fragmentierung und nicht Partitionierungs-Voraussetzungen.
„@macmark_de“
0
sierkb26.02.0915:57
MacMark
Wie lange bist Du schon am Mac?

Gute 2½ Jahre. Linux/Unix- und die wohl unvermeidbare Windows-Erfahrung deutlich länger.
Der Finder zwangs-verschiebt Dateien mit gedrückter Command-Taste.

Schon mal davon gehört, ja.
Abgesehen davon: die beiden Smileys hinter meiner gemachten Aussage hast Du gesehen (ich hätte wohl mehr davon dahintersetzen sollen...)?
Die Risiken sind nicht gleich: Ganze Platte weg (Defragmentierungstool) ungleich eine Datei weg (Finder-Move).

Naja, kommt drauf an, was man im Finder alles zum Verschieben markiert hat (ausprobieren tue ich das jetzt freilich nicht), oder?
Die Art der Fragmentierung, die beim Partitionieren stören kann, ist für alles andere in der täglichen Arbeit vollkommen unerheblich.

Wir reden hier von (De-)Fragmentierung allgemein. Das Thema/Stichwort Partitionierung bringst Du jetzt ins Spiel. Bisher haben wir davon eher nicht gesprochen, oder irre ich mich da?
OS X verhindert die Fragmentierung, die zu Geschwindigkeitseinbußen führen kann.

Offenbar tut es das aber nur zuverlässig bis zu einer Dateigröße von 20MB (Film-Dateien zum Beispiel sind oft größer als 20MB...), nach allem, was ich da zu diesem Thema bisher drüber lesen kann. Danach nicht mehr so zuverlässig bzw. eigentlich gar nicht. Auch Amith Sing schreibt das in seinem diesbzgl. Artikel , den Du ja in Deinen Ausführungen als Quelle angibst, und Du schreibst das mit dieser 20MB- bzw. 10MB-Grenze in Deinem Artikel ja auch.

Amith Sing listet in seinem Essay am Schluss ganz genau auf, zu welchen Bedingungen on-the-fly defragmentiert bzw. Hot-File-Clustering durchgeführt wird. Bedingungen, die offenbar alle gleichzeitig erfüllt sein müssen. Eine dieser Bedingungen ist eine notwendige Dateigröße kleiner 20MB, fürs Hot-File-Clustering sogar kleiner 10MB. Das wird in der Regel und bei den meisten vorkommenden Dateien sicher der Fall sein, sodass sie diese Bedingungen alle erfüllen und on-the-fly-Defragmentierung durchgeführt werden kann. Aber schon bei einer Dateigröße von leicht mehr als 20MB (ich nenne z.B. mal eine Filmdatei oder eine größere Audio-Datei) ist eine Bedingung fürs on-the-fly-Defragmentieren offenbar schon mal nicht erfüllt, und somit findet ein automatisches on-the-fly-Defragmentieren für diese Datei(en) wohl nicht statt...
Bitte korrigiere mich, wenn ich da was Falsches sage oder es falsch interpretiert habe.

Nebenbei bemerkt: auch schreibt Amit Singh in dem selben Artikel am Schluss, was seiner Meinung nach z.B. NTFS diesbzgl. und auch in anderen Dingen HFS+ zum Beispiel voraus habe bzw. besser mache als HFS+, aber das ist ein anderes Thema (ist mir nur zu meinem Erstaunen aufgefallen, als ich mir Singhs Essay nochmal durchgelesen habe)...
Beim Partitionieren stört jedoch nicht, daß einzelne Dateien eventuell fragmentiert wären, sondern daß nicht abnorm viel freier Speicher am Stück vorliegt, aus dem man eine zusammenhängende Partition erstellen könnte.

Wie zuvor schon gesagt: vom Partitionieren in diesem Zusammenhang reden wir bisher aber eigentlich nicht...
Mein Artikel behandelt Performance-relevante Fragmentierung und nicht Partitionierungs-Voraussetzungen.

Siehe zuvor Gesagtes.

Wie dem auch sei: mir geht's darum, dass deutlich wird, dass abseits vom Regelfall nach allem was wir bisher wissen, ein Zustand eintreten kann, dass die Festplatte mehr oder weniger an mancher Stelle durchaus fragmentiert sein kann und dass HFS+ mitnichten NICHT fragmentiert bzw. MacOSX mitnichten alles zu 100% selbst organisiert und bereinigt, sondern dies nur innerhalb gewisser Grenzen tut (das Gegenteil wurde und wird hier nämlich ab und zu mal gerne zur positiven Abgrenzung von anderen Betriebssystemen so in die Welt gesetzt bzw. die Nennung dieser Grenzen wird ganz gerne mal geflissentlich verschwiegen). Und dass es in so einem Fall entweder angeraten sein kann, auf ein Defragmentierungs-Tool zurückzugreifen, oder -- und das scheint wohl die meisten Anhänger zu haben, weil nach Ansicht der meisten sicherer -- (das etwas umständlichere) Umkopieren. Beide Möglichkeiten werden ja auch in einem betreffenden Apple Support Dokument in Betracht gezogen.

Interessant auch, was Amit Singh zu dieser letzeren Methode am Schluss seines Essays meint: "Although it would depend on a number of factors (such as a file's size, free space on the volume, and so on), if you simply moved (as a backup) a file with a highly fragmented fork to a new name, and copied it to the original name, the new copy might have lesser, or even no fragmentation, which you may check using hfsdebug. Please understand that I do not recommend that you do this! If you are really bent upon defragmenting your HFS+ volume, a more appropriate way would be to write your own defragmentation tool. The Carbon File Manager has functions that let you allocate contiguous space on a volume."
0
MacMark
MacMark26.02.0919:25
Amit nennt ein paar Eigenschaften, die NTFS hat, aber HFS+ nicht. Es sind jedoch keine, die mit Fragmentierung zu tun haben.

OS X hat hat diverse Mechanismen, die ich auch beschreibe, die der Fragmentierung entgegenwirken. Davon betreffen beispielsweise "das zusammengefaßte Schreiben mehrerer Dateien" und "das komplette Neuschreiben von Dateien bei Änderungen" auch Dateien über 20 MB Größe.

Es wäre natürlich Unfug, bei jeder Datei auf "ein Stück" zu bestehen. Daher gibt es einen Grenzwert für die Segmentzahl, ab der defragmentiert wird.

Im Endeffekt wirkt OS X und die jeweilige Anwendung einer Fragmentierung im vorgegebenen Maß entgegen, so daß keine Performance-Einbußen entstehen. Die Fragmentierung wird auf einem sinnvollen Level gehalten. Amit hat in der Praxis nachgewiesen, daß "Defragmentierung auf HFS+ nicht nötig ist und in den meisten Fällen auch nichts bringt, weil das System einen sehr guten Job darin macht, Fragmentierung zu vermeiden und ihr entgegenzuwirken." Er weist ferner darauf hin, daß Defragmentierungs-Tools die Situation verschlimmern können (Datenverlust).

Partitionierung setzt eine geringe Fragmentierung des freien Festplattenplatzes voraus. Die Fragmentierung des freien Plattenplatzes ist jedoch für den Normalbetrieb von wesentlich geringerer Bedeutung.
„@macmark_de“
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.