Ich habe den Thread mal hier eröffet, der Netzwerk/Internet-Bereich kam mir zu hardwaremäßig dafür vor.

Obwohl ja immer wieder Diskussionen darüber laufen, ob Mac-Festplatten nun fragmentieren oder nicht: Sie tun es auf jeden Fall, und gelegentliches Defragmentieren hilft. Dabei kommt es aber auch die Dateien an: Große Dateien fragmentieren, wenn nicht genug Platz an einem Stück vorhanden ist, der Spotlight-Index ist auch häufig fragmentiert. Eine weitere Quelle fragmentierter Dateien ist auch der Browsercache. Firefox legt pro Profil (Firefox-Profil, nicht Mac-Konto!) bis über 30.000 kleine Dateien an, die natürlich jeweils einen 4K-Block auf der Festplatte belegen. Das ganz ist also eine herrliche Platzverschwendung, viel Dateigewusel und erhöhte Fragmentierung.

Wie schafft man da Abhilfe? Das Löschen des Firefox-Cache geht doch vom Browser aus? Das schauen wir uns später an. Die Lösung liegt in der Erstellung eines Disk-Images. Man muß dann nur den Pfad des Caches ändern. Wie das geht, zeige ich hier.

Was benötigen wir:

- Firefox
- Festplatten-Dienstprogramm
- ein Dateibearbeitungstool (z.B. Path Finder)
- ca 1,5 GB freien Speicherplatz irgendwo auf dem System

Zuerst wird ein Diskimage erstellt. Pro Profil nutzt Firefox bis zu 1024 MB Festplattencache, also reichen für einen normalen Benutzer 1,2 - 1,5 GB locker aus. Das Image muß als .dmg erstellt werden (kein mitwachsendes .sparseimage), als Namen benutze ich FirefoxCache. Wo man das Image ablegt ist vollkommen egal, es kann im Home-Ordner sein, in /Benutzer/Alle Benutzer oder auf einer komplett anderen Partition oder Festplatte. Das wäre sinnvoll für SSD-Benutzer, so werden viele Schreibzyklen vermieden.

Wenn man jetzt ein Diskimage für den Cache benutzt, wird das natürlich dauernd auf dem Desktop angezeigt, das ist ja nicht Sinn der Sache. Also wird ein Manipulationstool benötigt, um das in den Volume-Informationen das Image auf 'unsichtbar' zu setzen. Ich benutze dafür den Path Finder.

Nun startet man Firefox. Um den Cache-Pfad zu ändern, gibt man in der Adresszeile about:config ein. Sucht dort nach dem Begriff 'cache'. Sofern er nicht existiert, erstellt einen neuen Eintrag

browser.cache.disk.parent_directory

mit dem Inhalt

/Volumes/FireFoxCache

oder wie euer Disk-Image heißt. Das war's dann auch schon, Firefox beenden und neu starten, dann sollte im Image ein Verzeichnis 'Cache' mit diversen Dateien und Verzeichnisen erstellt werden. Der alte Firefox-Cache muß noch gelöscht werden, dazu muß man Firefox beenden und im Homefolder in

Library/Caches/Firefox/Profiles/<yourprofile>

den Ordner Cache löschen, mehr aber nicht. Wenn man die Möglichkeit hat sollte man den Papierkorb umgehen, denn es können wirklich sehr viele Dateien sein. Path Finder bietet diese Möglichkeit.

Um das Image automatisch zu öffnen, muß man es dann nur in die Startobjekte ziehen, möglichst weit oben. Während des Starts erscheint dann ein kleines Fenster, das das Image geöffnet wird, mehr sieht man nicht. Das Öffnen dauert übrigens um so länger, je mehr Dateien drin sind. Also muß man die gelegentlich manuell löschen, mit Path Finder kann man in das unsichtbare Image gehen, mit dem normalen Finder muß man im Menü 'Gehe zu...' oder shift+command+G verwenden und dort dann /Volumes/FirefoxCache eingeben. Dort müssen die Dateien dann gelöscht werden, Firefox vorher natürlich beenden. Bitte nicht im Festplatten-Dienstprogramm formatieren, sonst wird das Unsichtbar-Bit gelöscht!

Wichtig: Dieses Image vergißt man gerne bei Disk-basierten Operationen, wenn das Laufwerk abgemeldet werden muß. Also z.B. bei der Reperatur oder beim Backup per Festplatten-Dienstprogramm, bei der Defragmentierung oder ähnlichem. Ein gutes Tool zum Erkennen von geöffneten Dateien eines Volumes ist 'WhatsOpen'.

Um zu zeigen, das es tatsächlich etwas bringt, habe ich mal einige Screenshots vorbereitet. Das Image habe ich am 10. Januar erstellt. Eine Woche später enthält es bereits über 35.000 Dateien! Bild:

Wer meint, den Firefox-Cache über den Browser selbst löschen zu können, kann sich dieses Bild hier anschauen:

Die Funktion bringt absolut NICHTS. Es wurden zwar knapp 3000 Dateien gelöscht, der Rest aber nur in einen 'Trash'-Ordner verschoben. Es kommen also zu den restlichen Cache-Dateien noch die neuen hinzu, eine gewaltige Quelle an Datenmüll. Für Windows habe ich eine Batchdatei geschrieben, mit der man den Firefox-Cache löschen kann, Windows XP und Vista/7/8 werden automatisch erkannt. Wenn Interesse besteht, kann ich die ja mal hochladen.

Schöne Grüße von naquaada.

Addon: Ich habe jetzt mal den Cache manuell gelöscht, und wie man sehen kann, ist selbst die Fragmentation der verbleibenden bzw. bereits neu von Firefox erstellten Cache-Dateien ziemlich hoch.

Ernstgemeinte Frage, kein Angriff: Was bringt mir das dann?

In Zeiten von SSDs und vernünftigen Browsern sollte das eigentlich kein Thema sein. Trotzdem ein tolles Tutorial.

Was die Bezeichnung 'vernünftiger Browser' bedeutet ist jetzt schwer zu sagen, aber Firefox ist der am weitesten verbreitete Browser und dank der vielen Plugins sehr flexibel. Und gerade im Zeitalter der SSDs sollte man Möglichketen finden, viele Schreibzugriffe zu vermeiden. Über 30.000 kleine Dateien auf der Festplatte erzeugen nämlich:

- einen Speicherplatzverbrauch von mindestens 4K pro Datei, selbst wenn sie nur 10 Bytes groß ist
- Freie Sektoren werden allokiert, die für andere Dateien sinnvoller sind
- Alle Dateien müssen im Directory bzw. Filesystem eingetragen werden
- Alle Dateien werden vom Spotlight-Index erfaßt, das dauert länger und der ist eh eine Fragmentationsquelle
- Die Firefox Cache-Verwaltungsdateien _CACHE_00x_ fragmentieren sehr stark, habe schon über 300 Fragmente in diesen Dateien gehabt

Durch die enorme Anzahl an Dateien entstehen sehr viele Schreibzugriffe (Erstellung, Directory-Eintrag, Spotlight-Index) was natürlich gerade bei SSD's nicht so gut ist, vor allem, da es sich nur um ziemlich unwichtige Dateien handelt. Die Methode mit dem Diskimage verhindert eine erhöhte Defragmentierung der Bootplatte, da ja nur in dem Bereich des Diskimages geschrieben wird. Bei einem System mit SSD und HD wäre das Bootsystem und der Homefolder ja auch auf der SSD, bei der ja eine Einsparung von Schreibzugriffen sinnvol ist. Das Diskimage kann man auch auf die normale Festplatte auslagern. So spart man auch Platz auf der Bootplatte.

Korrektur: habe oben 'erhöhte Defragmentierung der Bootplatte' geschrieben, das sollte natürlich 'erhöhte Fragmentierung der Bootplatte' heißen. Den Begriff Defragmentation benutzt man halt häufiger

Firefox ist eigentlich nur in Deutschland beliebt, der Rest der Welt setzt eher auf den IE und Chrome.

Man kann, um das eigentlichen Problem zu umgehen, auch einfach die maximale Cache-Größe minimieren. Spotlight erfasst diese Dateien übrigens gar nicht, da der Library-Ordner nicht indiziert wird. Außerdem haben SSDs seit Jahren kein Problem mit den paar Schreibzugriffen.

Nachtrag: Man kann im Terminal mit

sudo mdutil -i off /Volumes/FireFoxCache

den Spotlight-Index für das Laufwerk deaktivieren, das spart weitere Schreibzugriffe.


eiq:

Pro Datei brauchst du mindestens Directoryeintrag + Dateiinhalt + evtl. Spotlight-Index. Rechne das mal 35.000 in allein 7 Tagen... Was kommt das wohl pro Jahr zusammen? Und das sind ja nicht alle Cache-Dateien von Firefox, es kommen ja auch noch die Thumbnails und andere Sachen dazu.

Gegen bzw. für was? Auf einer SSD? Oder nur auf einer HD? Welche Sorte Fragmentierung meinst Du genau? "Internal" oder "external", siehe http://osxbook.com/software/hfsdebug/fragmentation.html

Was denn? Also was ist dieses "es", das gebracht wird? Welchen Nutzen soll das haben, was wird dadurch verhindert/vermieden?

Und? Wenn Du Firefox einen Cache im Dateisystem anlegen läßt, dann tut der das auch. Würde mich jetzt nicht so sehr überraschen, dass das dann tatsächlich auch geschieht...

Was will iDefrag denn da eigentlich mit den vielen Strichlein visualisieren? Funktioniert die OS X interne HFS+ Defragmentierung, die Apple in 10.3 eingebaut hat, heutzutage eigentlich a) auf SSDs und b) innerhalb Disk Images?

Wozu sollte man das tun? Also ausgerechnet einen Cache löschen (etwas, dessen Funktion idealerweise das einmalige Schreiben und dann wiederholte Lesen zur Beschleunigung von Vorgängen ist, also etwas, das prima auf eine SSD gehört). Funktioniert bei Dir die Funktionsweise eines Caches grundsätzlich anders?

Ich hab hier zwar das vermutlich seriöseste Programm, mit dem Fragmentierung auf HFS+ analysiert werden könnte (fileXray ), kann aber dummerweise das Ganze nicht nachvollziehen, da ich nur 'ne SSD habe, auf der Defragmentierung ja nicht nur nichts bringt sondern kontraproduktiv ist.

Wir setzen übrigens zur Vermeidung von "internal fragmentation" (also dem Fakt, dass normalerweise eine 1 Byte große Datei in HFS+ immer einen Block von 4096 Byte belegt) seit 10.6 auf das tolle Feature "transparente Dateikompression" in HFS+ (Stichwort com.apple.decmpfs und nachzulesen im Detail hier: http://arstechnica.com/apple/2009/08/mac-os-x-10-6/3/ ), das gerade in WORM-Situationen (write once, read many -- also hey, bei Caches, wenn man die nicht andauernd wieder löscht) was bringt, weil Apple da ein paar coole Sachen an HFS+ drangeschraubt hat, so dass kleine Dateien nicht mehr automatisch einen Block belegen müssen.

Thomas: Ich gehe auf deine Fragen gar nicht erst ein, ich sehe sie als rein provozierend an. Wenn du mal meine Posts gelesen hättest, wären viele Fragen gar nicht nötig gewesen.



Also ich benutze nur Festplatten, ich benötige keine SSD's. Eine 'dateisysteminterne Defragmentierung' soll auch in den Amiga-Dateisystemen PFS und SFS vorhanden sein, aber das konnte ich nie feststellen. Für eine effiziente Defragmentierung die Festplatte komplett abgemeldet werden muß, damit nicht wieder neue Daten auf die Festplatte geschrieben werden können.

Alle Arten von Speichermedien, Disketten, Festplatten, SSD's fragmentieren. Selbst eine simple Audiocassette 'fragmentiert' wenn man einen Titel mit einem kürzeren überspielt, es bleibt dann ein Rest vom alten drauf, den man dann vorspulen muß. Um das wieder hinzubekommen, müßte man die Cassette auf eine andere überspielen - sequentielle Datenspeicherung ohne Table of Contents eben Bei Track/Sektor-basierten Speichermedien werden solche Teile dann halt vom Dateisystem wieder als frei gekennzeichnet, es bleibt aber nach wie vor nur eine kleine Lücke, für den Rest muß ein anderer Platz gesucht werden. Wenn der freie Platz nur noch aus kleinen Lücken besteht, fragmentiert eine Datei halt. Ich bin mal gespannt, ob mir jemand ein echtes nicht-fragmentierendes Dateisystem zeigen kann, bei dem Dateien - egal wie groß - immer an einem Stück geschrieben werden. Und sollte ein Dateisystem in Ruhezeiten ohne Datenzugriff selbst defragmentieren, würde es bedeuten, daß ständig ein Schreibprozeß stattfindet, was natürlich gerade für SSD's ungesund sind.

Ich habe bereits im zweiten Satz darüber geschrieben, daß es stets Diskussionen über die Defragmentierung gibt - hatte ich doch recht damit. Wer irgendwie mit Computern zu tun hat, sollte wissen, daß Datenträger fragmentieren und daß es mal nicht schlecht ist, etwas dagegen zu tun. Man löscht ja auch gelegentlich mal alte Dateien, um wieder Platz auf dem Laufwerk zu bekommen. Wer meint, daß eine Defragmentierung nicht nötig ist, kann es lassen, aber es wird halt immer mehr werden. Selbst wenn man eine OS X-Installation auf einer komplett leeren Festplatte gemacht hat, wird bei ersten Systemupdates schon wieder eine höhere Fragmentierung vorliegen, da die neuen Dateien die älteren nicht 1:1 überschreiben können. Schon allein deshalb nicht, weil sie gerade vom Betriebssystem genutzt werden. OS X kann viel, aber es kann sich nicht selbst sauberhalten, da muß der User drauf achten. Ohne ein echtes Defragmentierungsprogramm geht es nicht.

Das ist so gesagt einfach falsch:
1) Ein Diskimage reduziert maximal die Anzahl an Dateien, die sich wild verteilen, indem sie diese auf den Platz des Images konzentriert. Die Anzahl an totalen Schreibzugriffen wird definitiv NICHT reduziert.
2) Einer SSD machen die paar Dateien nichts aus. Es sind nicht die Schreibzugriffe an sich, die SSDs zu schaffen machen, sondern die Anzahl an Schreibzyklen pro Sektor. Rechnung: Bei angenonmmenen 100.000 Schreibzugriffen für den Cache pro Woche (mehr als Du angegeben hast) ergibt das bei 4KB pro Stück 400MB pro Woche = 20 GB pro Jahr. Ein SSD-Block kann aber tausende Male beschrieben werden und die SSD-Controller und das OS verwalten das. Um die SSD zu schädigen müsste daher z.B. 3000 * 50 GB durch den Cache beschrieben werden. Das dauert dann etwa 3000 * 50GB / 20GB = 7500 Jahre, wenn die Schädigung rein durch den Cache produziert würde. Also vollkommen vernachlassigbar.
3) Ein Auslagern des Caches auf ne Platte ist ne echte Milchmädchentaktik. Caches werden warum verwendet? Ja genau! Um Dinge schnell im Zugriff zu haben. Z.B. beim vor- und zurück der Seiten in einem Browser müssen die Elemente nicht neu geladen werden. Das auf ein im Gegensatz zur SSD nicht nur bei der Schreib/Lesegeschwindigkeit langsames Medium wie eine HD zu verlagern, das auch noch sehr sehr viel langsamer auf kleine Dateien zugreift, das ist eine reinrassige Verschlimmbesserung.

Merke: Das Gegenteil von gut gemacht ist nicht ganz so selten das gut Gemeinte.

Ich will Dich echt nicht ärgern, aber man kann jedem nur von Deinem Vorschlag abraten.
Ansonsten kann man sagen: Die Defragmentierung wird am besten dadurch vermieden, dass man den Rechner gleich gar nicht nutzt.

Schade, dass Du das als Provokation betrachtest, denn der Versuch der Beantwortung all der Fragen hätte Dir hoffentlich geholfen, Dein metaphysisches Verständnis der Dinge, die auf Datenträgern und in Dateisystemen geschehen, zu überwinden.

Wenn Du vor Caches Angst hast, dann nutze sie doch einfach gar nicht (man kann das auch in Firefox einfach abschalten, dann wird nur im RAM gecached und beim nächsten Start ist der Firefox wieder schön langsam, weil er alles nachladen muß).

Wenn Du Dir über internal Fragmentation des Firefox-Caches Gedanken machst, dann kannst Du zum Held werden, indem Du den Mozilla-Leuten einen sinnvollen Feature Request für Firefox am Mac unterbreitest (leider erst nachdem Du Dich mal durchgerungen hast, Dich mit den Details von Dateisystemen allgemein und HFS+ im Speziellen, dem grundlegenden Unterschied zwischen SSDs und HDs, v.a. in Bezug auf external fragmentation, den Spezialitäten wie Wear Leveling bei SSDs, etc. pp. zu beschäftigen).

Aber wenn Du soweit bist, dann wärm doch einfach diese uralte Diskussion bei den Mozillanern wieder auf: https://bugzilla.mozilla.org/show_bug.cgi?id=514083 und schlag ihnen vor, dass sie in Zukunft unter OS X ab 10.6 bei der Ablage von Cache-Dateien auf HFS+ Dateisystemkompression einschalten sollen.

Wenn ich Dich richtig verstanden habe, würde das nämlich Dein Problem des "Verschnitts" von paar KByte je Cache-Datei größtenteils lösen. Warum mußt Du allerdings selbst lesen, die Links findest Du im Thread. Viel Spaß

Das Einfachste zuerst:

- Spotlight finden nicht statt, da bereits per "StdExclusions" Cache-Folder ausgeschlossen sind. Das Problem müsste man sich also erst mal -- bspw. durch Deinen DiskImage-Ansatz -- künstlich schaffen.

- DirectoryEintrag in HFS+ bedeutet einfach, dass ein Verweis auf Dateien/Verzeichnisse ins Catalog File aufgenommen wird. Bei mir sind in besagter Datei grad insg. 6.184.564 Einträge drin. Wenn eine Datei neu im Dateisystem angelegt wird, dann wird natürlich nicht sofort auch das Catalog File aufgefrischt sondern mehrere Requests gebündelt und dann irgendwann später auf einmal ans Ende des Catalog File angehängt (flush/purge wären die Suchbegriffe der Wahl bzgl. Details).

- "Dateiinhalt" belegt normalerweise 1-n "extent records", die auf "allocation blocks" gemapped werden. Wenn Du den Mozilla-Leuten erklärt hast, wie smart es wäre, wenn sie ihre Dateien einfach mit angeknipster Dateisystemkompression speichern (ist gerade bei Cache-Dateien, die einmal geschrieben und mehrfach gelesen werden, eine brilliante Idee), dann dürften alle die Dateien, die Dich heute so stören (also die richtig kleinen), anschl. nicht mehr direkt in Allocation Blocks landen sondern in einer anderen Datei, dem "Attributes File", da sie dann als Extended Attributes gespeichert werden (ggf. komprimiert), weshalb sie dann max. die reale Größe plus paar Byte obendrauf einnehmen und... tädää... wieder nicht dafür sorgen, dass sofort eine Datei erzeugt wird sondern das Ganze irgendwann mal als Update des Attributes File in einem Rutsch auf den Datenträger geschrieben wird.

Sowohl Catalog als auch Attributes File dürften größtenteils im RAM sein (ohne Dich endgültig verwirren zu wollen: aber da OS X auf Unix basiert und das Konzept dynamischen Pagings implementiert, ist es aus Sicht des OS nur eine Sache eines Pointers, ob eine Datei grad auf Datenträger oder im RAM ist), der Dateisystemtreiber ist natürlich soweit optimiert, dass Zugriffe gebündelt werden und die lowlevel-Treiber sorgen ihrerseits durch Command Queueing und anderen Schnickschnack dafür, dass das Storage-Device drunter richtig und effizient angesteuert wird.

Und erst jetzt, d.h. an dieser Stelle reden wir über Sektoren auf HDs und Blöcken bzw. Erasable Blocks auf SSDs (aber noch nicht von Flash-Zellen!). Und da kommt jetzt bei SSDs die Firmware daher und organisiert in Echtzeit Daten um, verschiebt physische Blöcke auf dem Medium, markiert andere als frei, etc. pp. -- da stecken viele viele Abstraktionslayer dazwischen und deshalb ist es auch völlig naiv, durch eine Minimierung von erzeugten Dateien einen positiven Effekt auf der Platte zu erreichen (da hat sich nicht nur ein Ingeneur in den vergangenen Jahrzehnten einen Kopf drüber gemacht, wie und was da alles optimiert werden kann).

Und drum ist das Problem, das Du eigentlich mit einer eher aufwändigen Methodik lösen willst, genau gar keines, wenn man sich dem Ganzen mit Wissen um die Vorgänge und Zusammenhänge nähert und dabei überholte Vorstellungen und fragwürdige Tools, deren Existenzberechtigung wohl alleine "kauf mich, mein Autor will was verdienen" ist, beiseite läßt

Irgendeine völlig vernachlässigbare Zahl. Ich hab grad auf die große Partition meiner SSD geschaut (439 GByte belegt mit über 2,6 Mio. Dateien, warum sollten da 35.000 pro Woche jucken? Sogar auf 'ner SSD. Ich hab mir so 'ne "neumodische" gekauft, die Wear Leveling und Garbage Collection nutzt und ich hab TRIM angeknipst, damit "leere Bereiche" des Dateisystems von den SSD-internen Optimierungen ausgeschlossen sind und damit effizienter und lebensverlängernder ablaufen. Bis in der SSD bei meinem Nutzungsprofil die beschreibbaren Blöcke bzw. Zellen ausgehen sollten, fließen noch viele Daten das HFS+ hinunter bzw. hab ich das Ding samt MacBook schon längst vertickt)

Übrigens: Da OS X "Dateisystem auf SSD" erkannt hat, wird sinniger- und richtigerweise nicht on-the-fly defragmentiert und findet auch kein Hot File Clustering statt. Alle Sorten Defragmentierung auf 'ner SSD sind ja sowohl sinnlos (ist halt keine rotierende Magnetscheibe mehr drin, wo die Anordnung von Sektoren noch irgendeinen Sinn ergeben hätte) als auch schädlich, weil sie mehr Schreibvorgänge und damit vermehrte Abnutzung der Zellen bedeuten würden:

Das ist wohl das grundlegendste Argument.
Und jetzt bin ich gebannt, ob Naquaada die Größe hat und nachdenkt und zugibt, dass er sich verrant hat, oder ob er schmollt.

Für ihn ja eher nicht, weil er keine SSD nutzt oder nutzen will (angesichts der Vorbehalte bzgl. falsch vermuteter Abnutzung der Teile könnte das aber ja sogar der Grund sein)

Seine Vorbehalte bzgl. "internal fragmentation" sind grundsätzlich ja richtig bzw. berechtigt, in der Praxis aber völlig irrelevant (sollte es stimmen, dass OS X je HFS+ im Laufe der Zeit die Inodes einfach hochzählt, dann kommt zu den fast 2,7 Mio. Dateien auf dem SSD-Startvolume hier noch über 173 Mio. inzwischen schon wieder gelöscht Dateien in den letzten 2 Jahren dazu (also nach Adam Riese dann im Schnitt fast 1,7 Mio. frisch erzeugte Dateien pro Woche?! -- Holla die Waldfee, da werd ich doch demnächst mal schauen, ob ich der SSD per S.M.A.R.T. oder sonstwie Infos bzgl. Aufbrauch von Blöcken entlocken kann):


Und "external fragmentation" bei HDs ist zwar grundsätzlich nach wie vor ein Rotierende-Magnetscheibe-immanentes Thema. Nach dem, was Apple diesbzgl. in 10.3 eingebaut und später angeblich noch bisserl verfeinert hat, würd ich da aber keine Sekunde drüber nachdenken und v.a. so Voodoo wie kommerzielle Defragmentierer meiden (dass die bzw. deren Autoren sich bemühen, potentielle Käufer eines anderen zu belehren, braucht ja nicht wirklich zu verwundern).

Ich rat ja gerne normalen Mac-Usern generell von allen Sorten "Systempflege" ab (Ausnahme: Erfahrene User und Bresink-Tools, weil die im Gegensatz zu fast all dem anderen Zeugs keine Voodoo-Verschlimmbesserer sind).

Einfach alle 2-3 Monate mal mit gedrückter Shift-Taste booten und fertig.

Find ich bisschen viel verlangt

Ich würd hoffen, er steigt in die Thematik bisserl ein, denn (vermeintliches) Fachwissen von vor halben Ewigkeiten bzw. davon abgeleitete Handlungsweisen bringen auf völlig andere Situationen gestülpt im besten Falle nichts, im schlechtesten Verschlimmerung. Und in der Öffentlichkeit abgekippt nur unnötige Verwirrung

Also von 35.000 Dateien bekomme ich net mal ein Jucken in der Hose. Aus wie vielen Dateien besteht alleine das OS? Das wäre relevant, wenn die TB-weise Platz belegen würden. Aber sonst?

Thomas Kaiser
Sehr gute Ausfuehrungen, gefaellt mir wirklich gut.

Hallo,

wie wäre es mit einer RAM Disk?

Wer Angst vor Dateien in Dateisystemen oder auf Datenträgern hat, kann das in Firefox ganz simpel per browser.cache.disk.enable=FALSE so machen lassen. Da braucht man auch keine "RAM Disk", weil der Firefox dann ganz von alleine nur Sachen im RAM des Rechners cached und damit alles nach einem Firefox-Neustart weg ist, so dass er dann wieder schön langsam alles aus dem Netz nachlädt.

Merke: Konzepte, die vor Ewigkeiten mal praktikabel gewesen sein mögen, taugen heute manchmal nur noch für kultische Zwecke (also wenn man sich einbilden will, irgendwas besser als sein Rechner zu können und deshalb mit nicht unerheblichem Aufwand "Systempflege" spielt, die im besten Fall nichts und im schlimmsten Verschlechterung verursacht)

Seufz.

Ich meinte damit, anstatt dass der Threadersteller sich extra ein Disk Image anlegt wäre es vielleicht sinnvoll, die Firefox Daten auf einer RAM Disk zu speichern.

dom_beta

Genau darauf hat dir Thomas geantwortet, also warum denn "Seufz"?!

So schlimm gleich?

Die spannende Frage ist doch: Warum sollte man das tun? Welches Problem soll das lösen? Das, das der Threadersteller beschreibt (das nunmal gar keines ist) oder das, das er de facto hat (ein überwiegend falsches Verständnis von den Vorgängen zwischen "eine Datei wird erzeugt" und dem, was auf Magnetscheiben oder Flashzellen ankommt -- und das leider auf jedem involvierten Layer falsch -- und davon abgeleitete völlig falsche Handlungsweisen)

Ich hab übrigens als ich neu zu OS X kam (war so um 10.2 rum, die schraddeligen Vorversionen hab ich mir gespart) gleich ein Skript geschrieben, um bequem RAM-Disks anlegen zu können:

Dann hab ich mich mehr damit beschäftigt, wie die Speicherverwaltung von OS X funktioniert, wie dynamisches Paging funktioniert, wie man die Ausgabe von Tools wie vm_stat und iostat interpretiert, wie Dateisystemfunktionalitäten von Systemversion zu Systemversion optimiert wurden, welche "Trade-Offs" bei Speicherkompression (egal ob im Dateisystem ab 10.6 oder im RAM ab 10.9) zu berücksichtigen sind. Und hab dadurch nebenher gemerkt, dass der Wunsch nach "RAM Disk" fast immer rein psychologischer Natur ist.

Wir hatten bei einem Kunden auf einem System jahrelang unter OS X 'ne RAM Disk im Einsatz, weil irgendeine Sortierfunktion in einer Library auf Teufel komm raus temporäre Dateien schreiben will. Bis wir dann mal Zeit hatten, die Wirksamkeit von "mount -o async" durchzumessen. Das tut, der Effekt ist der gleiche ohne den Nachteil einer RAM-Disk (konkret: dem System RAM zu klauen. Das OS kann das nämlich viel besser selbst verwalten als der davor sitzende User)

Mich wundert bei diesem "Unbrowser" auch gar nichts mehr...

Hast du den Thread überhaupt gelesen oder gar etwas davon verstanden? Firefox wurde von Naquaada nur gewählt, weil er die Möglichkeit bietet, den Speicherort der Cache-Dateien manuell zu ändern. Safari, Opera oder Chrome Cachen üblicherweise nicht weniger, Safari sogar deutlich mehr.
Wenn du also an Details wie dem Cacheverhalten einen »Unbrowser« festmachen willst, dann hast du leider den falschen getroffen.

Ja, habe ihn gelesen.
Es hört sich aber danach an, dass Firefox wieder am meisten Müll von allen produziert.

Offenbar aber nur die Überschrift. Sonst hättest Dir Deine beiden vorangegangenen Kommentare verkniffen und wüsstest selber, dass Du Unsinn dahergeredet hast.

Nur für den, der nicht verstanden hat oder nicht verstehen will (womöglich deshalb, weil er eine vorgefasste feste negative Meinung hat, die er sich durch nichts und niemanden, auch nicht durch anderlautende Fakten, erschüttern lässt). *kopfschüttel*

Ich frag mich ja seit paar Minuten (konkret seitdem ich feststellen durfte, dass Safari sein Gecache mittels CoreData , d.h. nicht in Form einzelner Dateien sondern als SQLite-Datenbank unter der Kontrolle von OS X erledigt) warum der Threadersteller nicht einfach Safari nimmt. Weil der "löst" sein "Problem" mit dem Verschnitt usw. usf. weil nicht Dateien im Dateisystem sondern Objekte in einer Datenbank landen, auf die mehrere Prozesse konkurrierend zugreifen.

Einfach mal 200 Tabs in Safari aufreißen, Seiten laden und nachgucken:

@sierkb: Falsch, ich habe auch die ersten 4 Posts gelesen.
Aber lassen wir das. Was rechtfertige ich mich...

Kurze Frage (sorry, habe nicht den gesamten Thread gelesen): Ist es nicht so, dass Mac OS X bzw. HFS+ seit Ewigkeiten "automatisch im Hintergrund" alle Dateien defragmentiert, die kleiner als 20 MB sind (wenn ich es recht in Erinnerung habe)?

Disk Warrior (mein persönlicher Favorit, da äußerst verlässlich) und iDefrag (nie probiert, kenne es nur vom Namen her) nützen demzufolge doch sowieso nur bei "größeren Dateien" etwas, oder?

Jap.

[quote=Marcel_75@work]
Kurze Frage (sorry, habe nicht den gesamten Thread gelesen): Ist es nicht so, dass Mac OS X bzw. HFS+ seit Ewigkeiten "automatisch im Hintergrund" alle Dateien defragmentiert, die kleiner als 20 MB sind (wenn ich es recht in Erinnerung habe)?

Jein. Das Ganze findet ab 10.3 nur statt, wenn HFS+ auf 'ner HD betrieben wird und wenn noch paar andere Randbedingungen parallel zutreffen (Details abermals: ). D.h. HFS+ auf einer HD wird mit der Zeit vermehrte "external fragmentation" aufweisen. Internal fragmentation tritt eh notgedrungen auf. Und beides ist völlig vernachlässigbar, weil "gut genug": Defragmentierung ist ab 10.3 ein weitgehend sinnloses Unterfangen, auf 'ner SSD wäre es sogar völlig bekloppt

Also, er möchte ja, seine Daten von FF auch nem Diskimage speichern. (Warum auch immer)

Sinnvoller fänd ich da eine RAM-Disk, weil nach einem Neustart sind die Daten weg und werden nicht auf der HDD gespeichert, sondern im RAM.

Wäre also optimal für ihn.

dom_beta

Alternativ kann man die Daten der RAM-Disk dann auch ausdrucken oder auswendig lernen.
Nach einem Neustart einfach via OCR respektive Eintippen wieder reinziehen, und schon flutscht der Browser wieder wie Sau, und das alles ohne die HD wuest zu fragmentieren, klasse ne?!

Darf ich auch mal seufzen?

Ok, also... Zugriffe aufs RAM sind gerne mal um Faktor zwölftrilliarden schneller als welche auf Platte. Faszinierenderweise haben das sogar Softwareentwickler schon begriffen. Unter anderem die Mozilla-Leute von diesem... äh... Firefox.

Und die haben jetzt lang und breit gerätselt, wie sie mit diesem Umstand umgehen sollten (weil RAM ist teuer und schnell, Platte aber billig und langsam). Deshalb hat der Firefox verschiedene Cache-Strategien implementiert bekommen und nutzt tatsächlich doch beides, cached also sowohl im RAM als auch Neustart-persistent auf Platte (sofern man das, wie in diesem Thread in nahezu jedem dritten Beitrag inzwischen wiederholt, nicht einfach abstellt, wenn man davor oder den fälschlich vermuteten Konsequenzen Angst hat: browser.cache.disk.enable=FALSE und der Lack ist geritzt).

Nun ist OS X ja kein MacOS 9 mehr und nutzt dieses komische Unix, von dem jetzt alle reden, und abseits des Firefox-eigenen Caches hat das Betriebsystem auch noch hinter jeder Ecke eigene. Wenn man bspw. eine Datei auf Platte schreibt und blitzschnell wieder lesen will (und asynchronen I/O verwendet), dann geschieht -- Wunder oh Wunder -- was völlig anderes: Es wird gar nichts von Platte gelesen, weil der ganze Kram noch im Disk-Cache des OS liegt (und die Datei finalmente erst nach dem vermeintlichen Lesevorgang überhaupt geschrieben wird. Davon kriegt aber weder das Programm, das lesen/schreiben will, noch der Anwender irgendwas mit, außer dass dieser "Plattenzugriff" sich -- Wunder oh Wunder -- genauso schnell anfühlt, als würde er aus dem RAM kommen (von wo er ja auch... na gut, lassen wir das).

Jetzt haben die Firefoxler doch allen Ernstes verschiedene Cache-Strategien gemischt und cachen so'n bisschen im RAM herum und so'n bisschen mehr auf Platte. Und wägen genau ab, möglichst nicht zu viel RAM zu ver(sch)wenden, denn da das Entwickler sind, wissen sie nunmal, dass dieses OS X noch so'n komisches UNIX-Zeugs implementiert, nämlich dynamisches Paging bzw. virtuellen Speicher: Aus Sicht des OS ist es eigentlich total wurscht, ob eine Speicherseite (page) auf Platte oder im RAM liegt. Ach so, der einzige Unterschied ist der, dass die Zugriffe aufs RAM immer noch zwölftrilliarden mal schneller sind, weshalb der dynamic_pager des OS auch lustigerweise ein strenges Regiment bzgl. der Speicherseiten führt und alles, von dem er glaubt, dass es nicht sooo dringend gebraucht wird, lieber auf Platte als im RAM läßt. Damit eben im RAM idealerweise vor allem das ist, auf das am häufigsten zugegriffen wird.

Jetzt haben sich paar kluge Köpfe schon seit Jahrzehnten einen eben solchen darum gemacht, wie man das endliche RAM eines Rechners ideal nutzen kann. Mal mit mehr, mal mit weniger Erfolg -- grad in frühen OS X Releases fand ich das eher Scheize -- aber man kann davon ausgehen, dass sich in der RAM-Ausnutzungs-Strategie des OS Mannmonate, wenn nicht gar Mannjahre Entwicklung widerspiegeln. Und dass das Betriebsystem das Ganze permanent und im Hintergrund und in einem Affentempo optimiert.

Das funktioniert auch alles gar nicht mal so schlecht, bis... ja bis dann mal wieder ein Mensch vor dem Rechner ein bisschen zu wenig nachdenkt aber natürlich alles ein bisschen besser als der Rechner können will.

Weil "RAM-Disk" (oder Defragmentierung oder irgendein anderer hilfloser Ansatz von "Systempflege"). Einfach dem Betriebsystem einen festen Anteil des Kostbarsten, was es hat, wegnehmen. Und dem Anwendungsprogramm, das spezielle Algorithmen für das Caching auf Platte hat, das geklaute RAM als Platte verkaufen wollen.

Was passiert nun in Folge: Cache-Dateien werden seitens Firefox nicht mehr für besonders schnelle Zugriffe im RAM gehalten und parallel auf Platte geschrieben (wegen Neustart überleben und so) sondern: sie werden jetzt einmal im RAM und nochmal im RAM vorgehalten! "Angenehmer Nebeneffekt": Da dem System jetzt auch weniger RAM insgesamt zur Verfügung steht, kommt es öfter zu sog. "pageouts", d.h. RAM-Speicherseiten werden auf Platte geschrieben und es kommt in Folge zu erhöhter Plattenaktivität (wenn man sich vor Fragmentierung fürchten sollte, wird man an der Stelle vermutlich noch mit einem Schaudern feststellen, dass ausgerechnet die pagefiles unterhalb /var/vm häßlichst vor sich hin fragmentieren)

Und mit dem Neustart des Rechnerns wird dann der Inhalt der RAM-Disk wahlweise weggeschmissen (womit der Effekt der Methode "Cache" erfolgreich konterkariert wäre) oder irgendwie aufwändig doch noch gesichert und beim nächsten Start ebenso aufwändig wieder in die RAM-Disk gesaugt (was wenigstens eines der Kriterien notorischer Systempfleger erfüllt: "es soll doch wenigstens aufwändig sein")

Das ewige Leid, wenn User schlauer als ihre Rechner sein wollen, tritt auch hier wieder gnadenlos ein: Das, was eigentlich erreicht werden soll, verkehrt sich ziemlich ins Gegenteil. Wie fast immer, wenn man sich einer vermeintlichen Aufgabenstellung nicht mit ausreichend Wissen und Methodik nähert, gilt: "Gut gemeint ist das Gegenteil von gut gemacht".

Jetzt klarer?

Keine Ahnung. Kontraproduktiv genug wäre es jedenfalls

Warum so kompliziert? Einfach ein gutes ZIP-Programm nehmen, die Daten auf 1 Bit komprimieren, und beim nächsten Start das eine Bit wieder mit der Maustaste einklicken und entzippen.

Ist der RAM nach dem Entzippen nicht furchtbar fragmentiert?

Thomas Kaiser
Grandioser Beitrag!

Ich sage bei einem Bekannten, der auch zu solchen Aktionen neigt, immer: "Let the machine do it!"

Die Zeit, die man verschwendet, um herauszufindent, wie man etwas (kaputt)optimiert, steht fast nie in einem Verhältnis mit der Zeit, die einem diese Optimierung einspart. So sie denn überhaupt etwas bringt.