Folgendes:
Ich möchte iLife '06 wieder installieren. Ich habe vor einiger Zeit mein Macmini komplett neu aufgesetzt.

Nun habe ich eine Systempartition, und eine Partition auf der meine Daten und Programme sind. Auf der Systempartition hat es jedoch zuwenig Platz um iLife zu installieren. In der Regel muss man die Programme ja nicht auf der Systempartition haben, aber iLife anscheinend schon.

Kann mir jemand helfen? Auf der System Partition habe ich noch 1.5 GB von 20 GB frei, was nicht ausreicht um iLife zu installieren. Und den Compute möchte ich auch nicht neu aufsetzen...

Werfe doch mal ein paar überflüssige Druckertreiber und Sprachpakete in den Müll, wenn es anders nicht geht.

das hilft dir momentan zwar nicht wirklich, aber ich würde das nächste mal einfach darauf verzichten, die platte überhaupt zu partitionieren, da das – quod erat demonstrandum – mehr probleme schafft, als es löst.

gibt es keine anderen möglichkeiten?

5.5 gb auf der systempartition zu löschen wird schwierig...

du könntest im festplattendienstprogramm die partitionsgrößen anpassen. also partionion 2 ein paar gbs klauen und der ersten hinzufügen. dafür einfach den Schieber zwischen den beiden Partitionen verschieben =)
vorrausgesetzt sind mit hfs+ formatiert.
Greez

die daten partition konnte ich verkleinern, die systempartition aber nicht vergrössern. was mache ich falsch?

Die eigentlichen Programme sind nicht sehr groß:
iMovie - 123 MB
iPhoto - 214 MB
iDVD - 150MB

Was viel Platz braucht sind die Themes und GarageBand-Samples und die liegenin /Library. Von da aus nach ~/Library verschoben (also wohl auf Deine DatenPartition) kannst Du sie zwar nur aus einem User heraus nutzen, aber das sollte klappen. iDVD hat bei mir 880MB Themes. Darüber hinaus kannst Du nach der Installation die Sprachpakete eindampfen, z.B. bei iPhoto hat jedes Locale-Verzeichnis ca. 20MB.

Trotzdem wirst Du nicht glücklich, denn das System legt auf dem BootVolume auch immer die Swap-Dateien an. Und die sind zusammen leicht mal >1GByte groß. Schonmal ausprobiert, die Systemplatte so voll zu schreiben, dass nur noch 50MB frei sind? Viel Spaß dabei :o)

Fazit: keine gute Idee, eine extra System-Partition anzulegen. Alte Windows-Angewohnheit

Peter

Ich finde, gerade bei kleinen, langsamen Platten lohnt es sich zu partitionieren. Besonders, wenn man chronisch volle Platten hat.

Ich hab meine Platte im MBP auch partitioniert und es macht sich einfach bemerkbar. Zum einen kann mir die Platte nicht derart volllaufen, daß das System abstürtzt, da, wenn überhaupt, eher die Datenpartition überläuft. Aber wichtiger ist: die Auslagerungsdateien werden im schnelleren ersten viertel der Platte angelegt (32GB System, 154GB User/Daten). Der Geschwindigkeitsunterschied ist spürbar (gute 50-60MB/s vs. 20-25MB/s).

Sicher, man nutzt die Platte nicht mehr so stark aus, aber die genannten Vorteile überwiegen IMHO bei weitem.

PS: Ich hab seit ich OSX benutze (2002) meine Programme (zumindest >90%) auf einer separaten Partition und bin damit immer SEHR gut gefahren. Ich hatte damit noch nie Probleme gehabt. Sogar unter Windows klappt das Problemlos (sofern der Entwickler eines Programms nicht im Vollsuff war).

da hast du wohl recht, allerdings sollte man dem system auch genügend platz lassen und nicht wie der TO.

ich meine mal irgendwo gelesen zu haben das der leo immer um die 5gb frei brauch. ich mein irgendwo stand mal das das system sonst instabiler wird und keine ahnung...vielleicht find ich den link noch...

Dies mag nicht von der Hand zu weisen sein, aber wenn Deine Systempartition zu klein ist, dann wird die dank Swap irgendwann mal richtig gut ausgelastet sein. Und wenn - wie im Beispiel - nur noch 1.5GB von 20GB frei sind und dann noch ein paar Programm dazu kommen, werden die Swap-Files schon gesplittet abgelegt und Essig ists mit den theoretischen Transferraten.

Peter

exAgrajag Partitionieren ist Quatsch. Und das noch bei kleinen Platten zu empfehlen erst recht. Also die Platte ist klein und dann ziehst Du noch künstliche Grenzen? Sorry, aber das ist ja fast schon sich beim Arbeiten sabotieren.

Das Argument mit System stürzt ab weil Platte voll ist, wird doch mit Partitionieren noch viel größer. Und das Swap-File wäre auch so im schnellsten Bereich wenn Du nicht mit AMIGA- und DOS-Wissen rumfummeln würdest, OS X würde die hot files selbst dort ablegen. Das macht es seit 10.3 selbstständig. Aber mit den zweckfreien Partitionsgrenzen dazwischen geht das natürlich nicht.

Alleine das zu kleine Platten nicht sein müssen da einem SATA und AT Platten in allen Größen förmlich nachgeworfen werden.

Garp2000: Es ist spürbar. Punkt. Du musst das ja nicht so machen. Ich werde es, bis ich SSDs benutze auch so weiterhin betreiben. Wo (nicht der Ordner, sondern die Position auf der Platte) werden die Swap-Files der Platte abgelegt? Ich hab auf die Schnelle nichts dazu gefunden, daß sie an bestimmten Plattenadressen abgelegt werden. Auch im OSX Internals hab ich auf die Schnelle nichts zu diesem Aspekt gefunden.

Der Vorteil liegt auch nicht nur in diesem Punkt. Da ich nahezu alle Apps in einem separaten Apps-Ordner habe, habe ich nach einer Neuinstallation auch nahezu alle Programme wieder am Start.



PS 1: DOS und Amiga habe ich übrigens nie benutzt.

PS 2: Ich wollte Partitionierung nicht unbedingt empfehlen, sondern ich wollte der Aussage, es wäre unsinnig, widersprechen. Es ist sicherlich nicht für jeden sinnvoll, für mich ist es das aber.

PS 3: Platten sind IMMER zu klein. Bis jetzt war bei mir noch jede Platte in kürzester Zeit wieder fast voll.

PS 4: Meine Systempartition hat trotz 3GB Sleep Image und 2GB Swap Files immer noch knapp 7GB frei – ich denke, das sollte locker reichen (tut es auch).

Du hast die Apps nach einer Neuinstallation auch so wieder. Migrations Assistent oder Drag & Drop erfüllen auch so ihren Zweck. Das ist doch unerheblich ob Du über Ordner- oder Volumegrenzen verschiebst.

Das Verhalten von OS X bzgl. Filesystem kannst Du Dir mit HFSdebug ansehen und in "Mac OS X Internals" nachlesen. Stichwort hot file clustering. Absolut interessantes Thema das Filesystem!

Ah, danke. Werde ich mal nachsehen. Hab kurz mal hfsdebug angeworfen. Muss aber erstmal gucken, wie man das interpretiert. Aber mein erster Eindruck ist, daß es wohl keinen definierten Platz für die Swapfiles gibt. swapfile0 scheint bei GB 22 zu liegen und swapfile6 in 9 Fragmenten zwischen GB 13 und 26. Aber das ist, wie gesagt, das erste Verständnis. Ich hab leider erst in 1-2 Wochen Zeit mich damit intensiver auseinanderzusetzen.

Aber danke nochmal für die Stichworte. Dadrauf wäre ich so schnell wohl nicht gestoßen.

Sicher, so geht es natürlich auch. Ich brauche allerdings nur kurz die DVD einwerfen, die System-Partition platt machen und hab dann in nicht mal einer Stunde ein voll lauffähiges System mit allen Apps und allen Usern.

Ich hatte übrigens schon zwei mal ein zerstörtes Verzeichnis meiner System-Partition gehabt. Da war es recht angenehm, nicht groß rumprobieren zu müssen. Einfach das System neu und gut.

Aber wie gesagt, man KANN es so machen. Es hat seine Vorteile. Allerdings hat es auch den Nachteil, daß man gut abschätzen können muss, wieviel Platz man tatsächlich für welche Partition braucht. Aber diese Erfahrungen hab ich schon sehr lange. Und man nutzt insgesamt etwas weniger Plattenplatz, da man ja bei jeder Partition genügend Platz lassen muss.

Und was TimeMachine angeht: Ich traue dem Ding irgendwie noch nicht. Ich benutze es zwar, aber derzeit mache ich noch auf die alte Weise zusätzliche Backups. Da weiß ich, was geht und was nicht. Ich hab jedenfalls kürzlich mein Timemachine-Backup löschen dürfen, nachdem das Backup für nur wenige 10 GB Ewigkeiten gebraucht hatte – genauer: ich hab das Backup morgens abgebrochen. Während des gesamten Backups war die Platte wie Wild am rumrödeln. Es waren noch um die 130GB frei (nachdem eine ältere Version gelöscht wurde). Das neue Backup flutscht jedenfalls wieder.

Überprüft Timemachine die Daten eigentlich nach dem schreiben?

=> Es spricht absolut überhaupt gar nichts gegen ein weiteres Backup neben der Time Machine. Wenn Deine TM-Festplatte kaputt geht nutzt sie Dir natürlich auch nix - ich selbst sichere meine wichtigen Sachen neben der TM im Drobo auch noch auf zwei zusätzlichen Festplatten, die nur zu Backups aktiviert werden.

Peter

twilight: Klar zusätzliche Backups sind nie verkehrt, besonders, wenn man dabei unterschiedliche Medientypen verwendet. Mir ist nur übel aufgestoßen, daß sich das Timemachine-Backup scheinbar zerlegt hatte. DAS darf eigentlich nicht passieren. Das ist fast noch schlimmer, als wenn das Medium selbst verreckt. Ich weiß noch nicht, was Timemachine genau macht. Bis ich dem Braten traue, fahre ich auf jeden Fall zweigleisig (bzgl. Sicherung auf Platten). Wenn ich mal wieder etwas Luft habe, werde ich mich mal etwas genauer mit Timemachine befassen.

Die Time Machine arbeitet eigentlich transparent. Beim ersten Backup (was dauern kann) wird prinzipiell alles kopiert, bei den darauf folgenden nur noch die Änderungen. Wenn Du in das TM-Verzeichnis schaust, siehst Du ja eigentlich in jedem Verzeichnis den kompletten Festplatteninhalt zum entsprechenden Zeitpunkt - das sind jedoch nur Hardlinks, die auf die entsprechenden Datei der vorherigen Backups zeigen. Wie schon angedeutet, läuft das erste Backup durchaus ne Weile aber dabei gilt: wenn möglich nicht unterbrechen. Bei den folgenden Backups isses praktisch egal, ob Du den Mac zwischenzeitlich schlafen legst oder Dir der Strom abhanden kommt.

Peter

Ok, der grobe Plot ist mir bekannt. Meine Frage ist z.B.: Wird jede übertragene Datei noch mal überprüft? Es könnten ja Bitfehler bei der Übertragung passieren. Was macht TimeMachine, daß das Backup zerstört werden kann? Ich kann mir vorstellen, daß die Verzeichnisstruktur durcheinander war. Ich hab leider vergessen die Verzeichnisstruktur vor dem Löschen der Platte zu überprüfen.

Timemachine war jedenfalls der einzige Prozess (von dem ich weiß), der auf diese Platte zugegriffen hat – naja, und Spotlight, das ja unbedingt ALLES indexieren muss, selbst dann, wenn man es nicht will. (Warum muss man sagen, was man NICHT indexiert haben möchte. Das sollte umgekehrt sein.)

exAgrajag,
twilight:

Time Machine speichert zwar Änderungen inkrementell ab, doch geschieht das dateiweise und nicht bitweise. Das ist dem Dateisystem HFS+ geschuldet, welches eben dateiorientiert ist und keine Änderungen auf Bitebene erlaubt. ZFS würde das erlauben. Das heißt im Klartext: Dateien werden komplett und am Stück gesichert und kopiert, auch wenn innerhalb dieser Datei nur ein einzelnes Bit geändert worden ist. Das wird sich erst mit ZFS ändern. Ein Beispiel, wo TimeMachine zum Beispiel lange fürs Sichern/Kopieren braucht: eine große, mehrere Gigabyte große binäre Datei einer Virtuellen Machine. Das kann dann zum Beispiel schon mal ein wenig dauern, wenn TimeMachine eine solche große VM-Datei sichert, obwohl sich vielleicht nur wenige Kilobytes oder Megabytes darin geändert haben.
Wie gesagt, mit ZFS würde sich das ändern, ZFS kann atomar und bitweise speichern bzw. Veränderungen kopieren. Im Zusammenspiel mit dem Dateisystem ZFS würde TimeMachine deswegen ganz sicher ziemlich entlastet und zu neuen Höhenflügen ansetzen können, weil bitweise tatsächlich nur das gesichert und aufgezeichnet würde, was an Änderungen innerhalb einer Datei stattgefunden hat.

@threadersteller: man kann mit pacifist prima programme woanders hin installieren, als es der Installer zulässt.

Ich würde einfach eine größere Platte einbauen. 20 GB sind recht knapp für heutige Verhältnisse.

gunar In der Tat, die ganze Diskussion ist in der Hinsicht sinnlos als das eine 120 Gig 2.5" SATA Platte gerade mal 40 Euro beim Elektroladen um die Ecke kostet. Damit haben sich dann alle Probleme der Kategorie "Anwendungen woanders installieren?" erledigt.

Seine SYSTEMPARTITION ist 20GB groß. Seine Platte ist, laut Info, 250GB groß. Ich glaub, da hilft eine 120er auch nicht wirklich weiter.

Haben sie nicht unbedingt. Aus Performance- und Wartungs-Gründen. Bestimmte Dinge lassen sich nämlich beschleunigen (Plattenzugriffe) bzw. entzerren, wenn man bestimmte Verzeichnisse/Dateien auf mehrere Partitionen/Platten verteilt. Die Swap-Datei bzw. Swap-Partition gehört dazu, verschiedene temporäre Verzeichnisse wie z.B. /tmp und /var gehören dazu bzw. können dazu gehören, und auch das /Users und /Applications-Verzeichnis kann durchaus dazugehören. Unix/Linux unterstützt sowas und sieht solche Szenarien vom System her vor, im Server-Segment ist sowas durchaus gängige Praxis bzw. erfahrene und schlaue Admins wissen davon, können damit umgehen bzw. praktizieren das. RAID profitiert zum Beispiel von sowas, und RAID 0 (Striping) ist nichts anderes, als seine Verzeichnisse auf mehrere Partitionen bzw. seine Partitionen auf mehrere Festplatten zu verteilen -- einer einfacheren Wartung wegen und auch einer Performance-Steigerung wegen.

exAgrajag OK, dann hätte er mal besser keine Partitionen gemacht Gut, aber bevor ich anfange uns jetzt alle wieder im Kreis zu drehen *g*

sierkb
Das ist Blödsinn.

Verteilung des Systems auf mehrere Partitionen einer Platte macht das System deutlich langsamer, da die mittlere Wartezeit für die Kopfpositionierung größer wird und die Trefferrate des Plattencaches sinkt.

Verteilung des Systems auf mehrere physische Platten kann in der Tat das System schneller machen.

Eine einzelne Festplatte hat normalerweise mehrere Köpfe und Platten. Und dann ergibt das durchaus wieder Sinn.
Unter Linux ist es z.B. üblich, eine eigene /swap-Partition zu verwenden statt einer Swap-Datei. Und diese /swap-Partition ist in einem besonderen Format formatiert und sollte möglichst gleich am Anfang der Platte liegen -- also innen und somit dort, wo die Positionierung des Kopfes aufgrund des kurzen Weges besonders schnell geht. Steigern kann man das noch, indem man diese Partition auf eine gleichschnelle oder schnellere Festplatte auslagert. Und steigern kann man die Performance erst recht, wenn man verschiedene belastete Partitionen voneinander abkoppelt und auf mehrere schnelle Platten verteilt, sodass paralleler Zugriff möglich ist.

Steigern kann man in manchem Fall aber auch durch geschickte Partitionierung die Wartbarkeit insgesamt, wenn bestimmte Verzeichnisse des Unix-Dateibaums auf unterschiedlichen Partitionen liegen. Das erhöht die Portierbarkeit und Update-Fähigkeit. Bzw. wenn eine Partition oder ein bestimmtes Verzeichnis (z.B. /var/log) zu eng und zu klein wird und zum Beispiel voll ist, dann wird sie einfach in eine neue Partition oder/und ein neues Laufwerk 1:1 kopiert/gespiegelt, per umount ausgehängt, und die neue, größere/schnellere Partition per mount einfach wieder eingehängt.

Nein, lies mal was Du vorher geschrieben hattest.

Es ist nicht hilfreich, erst die Sache A zu behaupten, und dann das Gegenteil davon, nur mit noch mehr Geschwätz drumrun getarnt.

Tue ich das? Wo?

Geschenkt.


Du meinst, alle diesbzgl. Tipps/Vorgaben/Hilfestellungen diverser Linux-Distributoren, FAQs und HowTos sind Geschwätz?

sierkb der osxnerd hat recht, lies Dir das geschriebene noch mal in Ruhe durch.

Wenn man auf jeden Voodoo-Tipp aus Windows- oder OS X-Foren hören würde... Die Linux-User werden auch nicht anders drauf sein.

Ich korrigiere mich. Deshalb

streiche: innen.
setze: außen. Weil die äußeren Zylinder der Festplatte schneller gelesen und beschrieben werden können als die inneren.

osxnerd,
Garp2000:

Pro-Linux: Tips zu Partitionen, Teil 2 (veraltet, aber dadurch nicht weniger gültig),
Fedorawiki.de: Partitionierung unter Linux ,
RedHat Dokumentation: Partitionieren des Systems ,
openSUSE: Installationshilfe ,
Linuxwiki.org: Partitionieren der Festplatte(n) ,
Linuxwiki.org: Partitionierung für Fortgeschrittene

etc. (es lassen sich bestimmt noch weitere Beispiele finden)

erzählen also eurer Meinung nach alle dummes Zeug, was Empfehlungen für eine sinnvolle bzw. leistungsfähige Partitionierung unter Linux angeht?

Dass sich bei Einsatz von LVM und RAID sowieso die Dinge neu ordnen, steht außer Frage.

osxnerd,
Garp2000:

Pro-Linux: Tips zu Partitionen, Teil 2 (veraltet, aber dadurch nicht weniger gültig),
Fedorawiki.de: Partitionierung unter Linux ,
RedHat Dokumentation: Partitionieren des Systems ,
openSUSE: Installationshilfe ,
Debian Manual: Partitionieren für eine Debian-Installation (Sparc) ,
Debian Manual: Anzahl und Größe der Debian-Partitionen (Mips) ,
Linuxwiki.org: Partitionieren der Festplatte(n) ,
Linuxwiki.org: Partitionierung für Fortgeschrittene

etc. Wahllos herausgegriffen. Es lassen sich bestimmt noch weitere Beispiele finden.

Die erzählen also eurer Meinung nach alle dummes Zeug, was Empfehlungen für eine sinnvolle bzw. leistungsfähige Partitionierung unter Linux bzw. Unix (für BSD-Systeme gelten verschiedene Dinge ganz sicher ähnlich) angeht?

Dass sich bei Einsatz von LVM und RAID sowieso die Dinge neu ordnen, steht außer Frage.

die theorie solcher für den normalanwender völlig überzogenen partitionierungs-, dateisystemverteilungs- und was-weiß-ich-orgien mag ja für den geek reizvoll sein, allerdings halte ich sie in zeiten aktueller festplattentransferraten und im vergleich zu vor einigen jahren wesentlich verbesserter zugriffszeiten für in der praxis völlig irrelevant und eher der einfachheit und wartungsfreundlichkeit eines systems kontraproduktiv entgegenstehend.

man möge mir subjektiv im bereich ab 30% verbesserung zu bemerkende vorteile zeigen und ich beschäftige mich damit. bis dahin mag das für hochleistungssysteme, die eh immer am anschlag arbeiten sinnvoll sein, für alle anderen ist das wie die beschäftigung mit der frage nach der existenz dunkler materie.

oliver:

Findest Du. Finden andere, die sich ebenfalls mindestens genauso mit der Materie beschäftigen, möglicherweise/wahrscheinlich nicht bzw. sehen das etwas anders.

Völlig OT und abseits von allem: dieses frisch im Web kursierende Video zeigt eindrucksvoll (und irgendwie erschreckend), wie empfindlich Festplatten heutiger Zeit reagieren können ...

Du hast behauptet, Partitionierung würde die Geschwindigkeit erhöhen. Das ist nachgewiesenermaßen Quatsch.

Danach erwähnst Du das nicht mehr, sondern behauptest, Partitionierung würde die "Wartbarkeit" erhöhen (was eigentlich auch Unsinn ist, es sei denn, man hat ein so unzuverlässiges System, dass einem dauernd die Dateisysteme kaputt gehen).

Das versteckst Du in ellenlangen Linux-Ausführungen, die auf Mac OS X nicht anwendbar sind.

Ja, denn zum einen diskutieren wir hier nicht über Linux, zum anderen stammt dies alles aus einer Zeit, als Festplatten klein und teuer waren und noch nicht mit linearer Blockadressierung gearbeitet haben (was es dem Betriebssystem so gut wie unmöglich macht, zu entscheiden, welche Teile einer Festplatte "schneller" sind als andere).

osxnerd:

Wo behaupte ich das so explizit und generell, wie Du es darstellst? Ich bin lediglich Deiner Behauptung, die Du hier explizit wiederholst, entgegengetreten, dass Partitionierung generell Quatsch sei.

Wo behaupte ich das bzw. stelle das einfach unbelegt so in den Raum bzw. wo deckt sich das, was ich schreibe bzw. geschrieben habe, nicht mit den Quellen, die ich angeführt habe (allen voran denen von Red Hat, Debian, openSUSE, LinuxWiki etc.)?

Belege Du bitte, WARUM das alles angeblich Unsinn sein soll. Ich habe Quellen genannt, die teilweise sehr ausführlich und nachvollziehbar darlegen, warum es Sinn hat, wann es Sinn hat und wie es Sinn hat. Bitte belege Du, warum das alles keinen Sinn hat und schreibe die genannten Quellen bitte alle an und bitte um Korrektur, dass sie da alle was Falsches in die Welt setzen und weiterverbreiten.

Stimmt, ich vergaß. MacOSX ist ja kein Unix. Die Regeln und Optimierungsmöglichkeiten, die auf andere Unix-Systeme anwendbar sind, gelten hier ja nicht bzw. scheiden prinzipiell aus...

In den von mir aufgeführten Quellen wird u.a. schön und verständlich dargelegt, warum Partitionierung für kleine wie für große Festplatten Sinn ergeben kann bzw. warum und an welcher Stelle eine Partitionierung selbst bei einer einzelnen großen Festplatte und bei unerschöpflichem RAM noch einen Sinn ergeben kann...

Es geht hier bei der Diskussion nicht darum, dass Partitionierung IMMER sinnhaft ist bzw. zwangsweise einen Perfomance-Schub ergeben MUSS, ich bin lediglich der hier aufgestellten Aussage/Behauptung entgegengetreten, dass Partitionierung auch bei einer einzelnen Festplatte angeblich generell und immer überflüssig und sinnfrei sei. Und für genau diese Behauptung, die Du wiederholt hier zum Besten gibst, hätte ich ganz gerne mal stichhaltige Quellen genannt. Ich habe Quellen genannt, die das Thema näher beleuchten und wo weitere Informationen und Erklärungen genannt sind. Und Du? Wo sind Deine Quellen, die Deine generalisierte Behauptung stützen? Wo kann ich nachlesen bzw. belegt finden, dass Du mit Deinen Aussagen im Recht bist?

sierkb

"Stimmt, ich vergaß. MacOSX ist ja kein Unix. Die Regeln und Optimierungsmöglichkeiten, die auf andere Unix-Systeme anwendbar sind, gelten hier ja nicht bzw. scheiden prinzipiell aus... "

Nunja, eine Anleitung die von einem Minimal-Filesystem ausgeht das eben nicht wie HFS+ on-the-fly-defrag und hot-file-clustering beherrscht, ist zwar nicht unbedingt falsch - aber leider deswegen noch lange nicht richtig. D.h. bezüglich Geschwindigkeitserhöhung bringt uns so eine Anleitung nicht weiter.

eine verlegung von var, swap auf eine schnellere/bessere bereiche, bzw. gleich auf eine zusätzliche kleine platte, ssd(gibt es auch zum einschieben für cardbus/express slot) beschleunigt das system sehr wohl.

Partitionieren Sie weise und großzügig.

Wo liest Du irgendwas von einem Minimal-Filesystem?

HFS+ fragmentiert irgendwann auch. Wie fast jedes andere Filesystem auch. Selbstheilung in dieser Richtung kennt HFS+ nicht. HFS und HFS+ sind betagt, das weißt Du auch. Da gibt es einige schwerwiegende Baustellen, die es aufzuarbeiten gilt. Auch das weißt Du. HFS bzw. HFS+ ist beileibe nicht das Vorzeige-Dateisystem vor dem Herrn und hat einige Schwächen bzw. man merkt ihm eben an, dass es betagt ist und auf einem alten Rumpf sitzt. Ansonsten wäre die Dringlichkeit bzgl. des Bedarfs für ein neues Standard-Dateisystem wie z.B. ZFS eines werden könnte, wohl nicht gegeben. Dass dem anders ist, weißt Du ebenfalls.

Von daher bringt uns dieser Einwand von Dir und die nähere Beschäftigung mit HFS+ genau null weiter.

Ich habe auch nirgends behauptet, dass so eine Anleitung uns zumindest unter MacOSX weiterbringt. Diese Anleitungen veranschaulichen lediglich, dass Partitionierung und Aufteilung von diversen Verzeichnissen auf unterschiedliche Partitionen/Volumes durchaus sinnvoll ist bzw. sein kann und auch unter BSD-Systemen mit ihren Slices üblich ist bzw. praktiziert wird.

MacOSX verwendet zum Beispiel standardmäßig eine Swap-Datei. Warum sollten hier nicht genau dieselben Begründungen und physikalischen Regeln gelten wie unter anderen Unix-Systemen auch, wenn z.B. die Swap-Informationen zum Beispiel nicht in eine Datei geschrieben würden, welche der Dateiverwaltung unterliegt und somit das Ganze beim Schreiben/Lesen ausbremst, sondern in eine eigens dafür angelegte Partition mit eigens dafür optimierten Sektoren und Inode-Größen?
Was ist, wenn man z.B. den Swap-Space erhöhen will oder muss? Bzgl. einer Datei muss man die Datei vergrößern, was sie evtl. wieder auf der Festplatte verteilt bzw. ungünstig irgendwo auf der Festplatte positioniert. Hat man eine eigene Partition dafür reserviert, so ist die fest und liegt idealerweise ganz am Anfang eines Datenträgers. Braucht man mehr davon, nimmt man einfach eine weitere Swap-Partition (die man entweder auf derselben Festplatte oder besser auf einem anderen schnellen Datenträger angelegt hat) und sagt dem Betriebssystem einfach, dass es diese neue Swap-Partition zur bisherigen dazu rechnen soll. Wahlweise wird dann im Round-Robin-Verfahren die Last zwischen beiden verteilt.

Was ist mit möglichen parallelen Zugriffen auf z.B. /usr und /usr/lib? Zum Beispiel, wenn der Rechner irgendwas intensiv kompiliert?
Viele Unix-Programme erfordern das dynamische Nachladen von Bibliotheken. Wird also ein Programm aus /usr/bin gestartet, werden meist noch eine Reihe von Bibliotheken aus /usr/lib geladen. Das geht schneller, wenn beide Verzeichnisse auf getrennten Platten oder in getrennten Partitionen, die weit vorne auf der Platte liegen liegen...

Ähnliche Überlegungen legen eigene Bereiche für /var und /tmp ... nahe:
Angenommen wir haben eine simple Installation vorgenommen und die Platte garnicht aufgeteilt oder nur in die Bereiche für den Swap-Speicher und eine Partition für den Rest aufgeteilt. Viel freier Speicher ist nicht mehr übrig geblieben, dafür laden sich die Nutzer oder der einzelne Nutzer fleißig die dicksten Filme aus dem Netz... Nicht mehr lange und der Vorrat an Speicherkapazität ist erschöpft.

Was wird passieren? Niemand wird mehr vernünftig mit dem System arbeiten können, da kein Prozess mehr vermag, seine Statusdaten abzulegen. Der Systemverwalter will sich anmelden und per Hand Platz schaffen... und scheitert, da nicht mal ihm Ressourcen zur Verfügung stehen. Unter Umständen muss das System neu gestartet werden.

Es gibt/gäbe also durchaus auch unter MacOSX (eben weil unter der Haube ein Unix arbeitet und bestimmte Gesetzmäßigkeiten und Anwendungszenarien sich betriebssystemübergreifend ähneln bzw. gleichen) Szenarien, die durchaus plausibel machen könnten, warum eine sinnvolle/geschickte Partitionierung auch bei einer einzigen Festplatte generell sinnhaft sein kann und auch unter MacOSX alles andere als sinnfrei sein könnte, wenn man es auch dort machen würde. Warum sollte das Unix namens MacOSX hier eine Ausnahme gegenüber anderen Unix-Derivaten sein, wenn dort gewisse Maßnahmen schon seit Jahren sinnhaft und im Einsatz sind -- auch mit einer einzigen Festplatte und genügend RAM?

Hab ich das richtig verstanden? Hot file clustering kümmert sich nur um Dateien mit max. 10MB? Da hilft mir auch nichts, wenn die VM-Dateien über die Platte verstreu werden.

Und so wie es ausschaut, liegen MEINE VM-Dateien (in sehr vielen Fragmenten) quer über die Sytsempartition, mit eindeutiger Tendenz am Ende der Partition. Und so war es auch, ohne es wie jetzt explizit nachgesehen zuhaben, als ich noch eine unpartitionierte Platte benutzt hatte. Die VM-Dateien lagen eher im langsamen Bereich der Platte. Und dieser Bereich ist nun mal gerade mal halb so schnell, wie der Bereich, wo die VM-Dateien jetzt, also bei meiner partitionierten Platte, liegen.

Ich meine, ich bilde mir die erhöhte Geschwindigkeit beim Zugriff auf die Auslagerungsdateien nicht ein.

exAgrajag:

Auch Time Machine und Spotlight kranken am betagten HFS+-Dateisystem bzw. der Aufteilung von MacOSX insgesamt bzw. können dort nicht zu ihrer Hochform auflaufen oder schlimmer: bremsen das gesamte System aus bis teilweise hin zur völligen Blockade, weil das bisher zugrundeliegende Dateisystem eben einige Dinge nicht beherrscht und nur sehr suboptimal oder gar nicht kann. einige angedachte Dinge für Time Machine sind zum Beispiel mit HFS+ derzeit nicht machbar, nicht lösbar. Der Umgang mit kleinen bzw. sehr kleinen Dateien (die eben zum Beispiel u.a. auch beim Swappen, aber eben auch im Umgang mit mail etc. anfallen) gehört da leider dazu. Auch deshalb wird von vielen eine Ablösung bzw. generelle Überarbeitung des 20 Jahre alten HFS-Dateisystems (HFS+ setzt auf alten HFS-Konzepten auf) von zum Beispiel ZFS herbeigesehnt. Siehe auch z.B. der diesbzgl. hervorragende Artikel auf arstechnica .
[/quote]

sierkb:
Im Beitrag vom 20.01.09 10:06.

Im Beitrag vom 20.01.09 13:46.

Ich habe bereits die technischen Gründe genannt, warum das Unsinn ist.

Sonst geht's Dir noch gut, oder?

Manche schon, manche nicht. Du solltest den Unterschied zwischen einem BSD-basierten Unix und einem System-V-basierten Unix schon kennen.

Es ergibt sich schon nach dem gesunden Menschenverstand, dass eine Partitionierung einer Platte in n Teile dazu führt, dass deren wichtigste Datenstrukturen (die Verzeichnisse, Journals, Belegungsverwaltung, etc.) in n möglichst weit auseinanderliegende Teile "fragmentiert" werden. Die näheren Details über die daraus zu erwartenden Latenzen, Warteschlangen, etc. kannst Du in jedem Lehrbuch über Betriebssystemarchitektur nachlesen.

Genau. Hier haben wir zum Beispiel eine große Schwäche von Linux im Vergleich zu Mac OS X: Dort ist ohne Anschließen einer zusätzlichen Platte oder Bereitstellen einer zufällig freien Partition keine Vergrößerung des Swap-Bereichs möglich. Mac OS X macht das dynamisch, wenn nötig.

Woher willst Du bei einer modernen Platte wissen, wo der "Anfang" ist?

Nein, es geht nur schneller mit getrennten Platten. Es geht im Mittel langsamer mit getrennten Partitionen der gleichen Platte, da Du durch die Partitionierung die Wahrscheinlichkeit reduzierst, dass die mittlere nötige Kopfbewegungslänge zwischen einem Zugriff auf /usr und /usr/lib kurz ist.

Absolut richtig. Daraus ergibt sich, dass die Partitionierung dieser einzelne Platte unsinnig ist, denn Partitionen sind kleiner als die ganze Platte. Die Wahrscheinlichkeit, dass Platz zu klein wird, steigt.

Es ist Dir entgangen, dass die ganzen Beispiele, die Du hier aus der Linux-Welt zitierst, dazu dienen, Dateisysteme aus mehreren Platten zusammenzumounten. Das geht natürlich ganz genauso in Mac OS X und in jedem anderen Unix-System und erhöht die Geschwindigkeit. Es ist aber völlig sinnlos und reduziert die Systemleistung, eine einzelne Platte erst zu partitionieren und sie danach wieder per Mount zu vereinigen.

Mit welchem Satz, welcher Formulierung genau? Ich ahne ja, worauf Du zielst, aber ich möchte es gerne nochmal explizit von Dir wiederholt bekommen. Evtl. ziehst Du das nämlich in einen Kontext, in den es nicht gehört bzw. Du drehst es Dir so, wie es Dir grad' passt...

siehe zuvor Gesagtes. Ich halte meine Formulierung weiterhin aufrecht, habe davon nichts zurückzunehmen.

Wenn ich jetzt bös' wäre, würde ich sagen: nein, das behauptest Du einfach bzw. das stellst Du einfach in den Raum. Und unterstellst mir dann einfach, ich würde irgendwas behaupten. Ich hätte gerne von Dir Quellen genannt, die Deine Aussagen, so wie Du sie getätigt hast, so belegen. Ich habe bereits Quellen genannt, die meine Argumentation stützen, von daher behaupte ich nicht nur einfach, sondern ich untermauere meine Argumente mit Quellen (es gibt teilweise sicher bessere Quellen, ich weiß, aber ich nenne wenigstens welche). Du bisher nicht. Du bist Deine Belege und Quellen, die Deine Argumentation, so wie Du sie bisher tätigst, bisher schuldig geblieben... Von daher bist bisher wohl eher Du derjenige von uns beiden, der hier einfach irgendwelche Behauptungen in die Welt setzt, ohne sie durch Quellen oder Dritt-Meinungen zu belegen.
Ich lerne gerne dazu bzw. gestehe gerne ein, dass ich da was Falsches gesagt habe, aber solange Du Deine Argumente nicht unterfütterst und mir bzw. dem geneigten Mitleser irgendwelche Quellen/URLs nennst, die Deine Argumente unterfüttern, so muss ich Dir leider widersprechen. Erst recht, wenn Du hier so schroff und vom-Tisch-wischend auftrittst.

Nein, den Schuh musst Du Dir anziehen. Du hast mich in die Ecke gestellt, dass ich da angeblich falsches Zeugs behaupte. Ich habe meine Argumente aber wenigstens versucht zu belegen und zu untermauern. Du bisher nicht. Dir soll man einfach Dein Gesagtes so ungeprüft glauben, Du bist frei davon, irgendwas belegen zu müssen, was Du da sagst. Warum eigentlich? Also: belege und untermaure bitte Deine Argumente, und wenn Du das nicht kannst oder willst, dann stelle einfach nicht irgendwelche hier nicht unterfütterten Behauptungen auf und zeihe andere der Blödfaselei.

Kenne ich. Was tut das hier konkret zur Sache? Abgesehen davon: wenn das auch unter BSD-Systemen so unsinnig ist, weshalb gibt es dann auch dort Slices zw. Partitionen bzw. weshalb unterstützt selbst dieses FreeBSD-Dokument (welches ich jetzt zufällig und ad hoc gefunden habe) meine bisherige Argumentation Deine jedoch nicht?

Ich will hier nicht irgendwas aus Deinem oder meinem gesunden Menschenverstand wissen, ich möchte gerne einen Beleg für das, was Du bisher zum Besten gibst: das Partitionen generell (und unter MacOSX anscheinend sowieso) Schwachsinn sind und angeblich eher eine Performance-Bremse sind denn ein Vorteil und dass eine einzige Partition, wo alle Verzeichnisse drinhängen generell und immer (ganz besonders unter MacOSX) und unbedingter Vorteil. Bitte wo kann ich das nachlesen? Bitte nenne mir eine oder mehrere URLs bzw. Anlaufstellen im WWW, wo ich das nachlesen und mich diesbzgl. bilden kann...

Mit Verlaub: das ist Quatsch und Schachfug, den Du da von Dir gibst.
Das geht unter Linux so ziemlich genauso wie unter FreeBSD bzw. anderen BSD-Systemen. Swap lässt sich dynamisch allokieren, oder anders gesagt: mehrere Swap-Partitionen/Laufwerke lassen sich bei Bedarf im laufenden Betrieb ziemlich schnell und mit wenigen Handgriffen/Befehlen zusammenschalten, ein- und ausschalten, um die Größe zu variieren und die Prioritäten zu verteilen. Schnellere Datenträger, die hier in so einem Verbund sind, können z.B. eine höhere Priorität bekommen, langsamerer eine niedrigere.

Und deshalb ist u.a. hier: für FreeBSD davon die Rede, es möglichst genau so zu machen, wie Du bemängelst: nämlich in eine eigens dafür angedachte Partition...

So wie jedes Linux/Unix auch. Nur, dass man dort, wenn man schlau ist, eine eigene und dafür optimierte Partition wählt mit entsprechend klein dimensionierten Inodes und keine Swap-Datei, wie das bei MacOSX der Fall ist. Eine auf ihren Zweck hin optimierte Swap-Partition ist mit Sicherheit schneller im Zugriff als Swap in eine Datei geschrieben wird unter einem Dateisystem HFS+, welches bekanntermaßen teilweise eklatante Schwächen im Umgang mit kleinen und sehr kleinen Informationshäppchen/Dateien hat. Auch deshalb bemüht sich Apple um ZFS, weil ZFS diesbzgl. besser mit kleinen Informationshäppchen umgehen kann als das bisherige HFS+.

Der liegt immer außen. Auch bei Zone bit Recording. Eine Festplatte wird seit jeher von außen nach innen beschrieben. Es wäre mir neu, wenn sich daran etwas geändert hat.

Mit getrennten Platten, die mindestens gleich schnell sind, geht es IMMER schneller, das habe ich auch bisher immer gesagt und nie angezweifelt.

Gegenargument zu Deiner Aussage bzgl. einer Platte: hast Du nur eine einzige Partition, hast Du keinen Einfluss darauf, wo /usr und wo /usr/lib liegen. Sie können irgendwo liegen, sie können auf insgesamt eher ungünstigen Positionen liegen und weit auseinander liegen. Stellst Du eigenen Partitionen für /usr/ und /usr/lib bereit, dann hast Du bei der Partitionierung die Freihei, sie einerseits dort anlegen zu lassen, wo es strategisch günstig ist (z.B. auf en äußeren Zylindern der Festplatte) bzw. wenn sie unmittelbar hintereinander erstellt werden, dann werden sie sicher auch unmittelbar nebeneinander auf der Platte liegen. Zugriffsbewegungen des Kopfes können hier also mehr optimiert werden, als wenn man alles in einer einzelnen Partition hat und einfach nur darauf vertraut, dass das OS diese Bereiche schon irgendwie optimal platziert hat. Im ungünstigen Fall sind sie nämlich eben NICHT optimal platziert bzw. schön verteilt auf der Festplatte.

Hast Du meine Links eigentlich aufmerksam gelesen? Da steht teilweise drin, warum es auch bei einer einzelnen Platte noch sinnvoll und eine Gewinn sein kann, diese zu partitionieren.

Du kannst mir sicher auch eine seriöse Quelle nennen, die Dein Gesagtes bestätigt und wo man das nachlesen kann. Oder?
Ich lerne gerne dazu, revidiere gerne mein bisheriges Weltbild. Aber nicht allein aufgrund irgendwelcher Behauptungen Deinerseits. Wenn Du sie glaubwürdig mit nachlesbarem Material unterfütterst, dann gerne. Aber nicht so.
Einfach irgendwas in die Welt setzen (sprich: behaupten) und heimlich drauf hoffen, dass es jemand glaubt, kann jeder. Und genau das tust Du bisher. Sorry, ich möcht's gerne noch woanders nachlesen und verifizieren, bevor ich Deinen diesbzgl. Worten/Behauptungen Glauben schenken kann.

sierkb
Mit dem Satz "Bestimmte Dinge lassen sich nämlich beschleunigen (Plattenzugriffe) bzw. entzerren, wenn man bestimmte Verzeichnisse/Dateien auf mehrere Partitionen/Platten verteilt.".

Mit dem Satz "Steigern kann man in manchem Fall aber auch durch geschickte Partitionierung die Wartbarkeit insgesamt".

Du scheinst dem generellen Irrtum zu unterliegen, eine Quelle würde eine Aussage belegen, im Sinne von "Beweisen". Dabei vergisst Du dass die Aussagen, die Du triffst, keine Zitate aus den Quellen sind und in vielen Fällen nichts direkt mit der Quelle zu tun haben, da Du sie nur als "nähere Informationen über viele Dinge, die aber mit dem diskutierten Thema nichts zu tun haben" verwendest. Das Heranziehen einer Quelle bedeutet auch nur, dass es jemanden gibt, der der dort vertretenen Ansicht ist, nicht dass die Ansicht stimmt.

Nein, Du hast die Sache nicht verstanden. Wie vergrößerst Du den Swap-Bereich unter Linux, ohne eine Platte neu anzuschließen, bzw. ohne dass eine bereits vorhandene Partition als Swap-Bereich umgewidmet wird? Baut das System selbst eine neue Platte ein oder löscht irgendwelche anderen Partitionen?

Auch das hast Du nicht verstanden. Eben weil man gerade keinen Einfluss nimmt, ist der Erwartungswert für den mittleren physischen Abstand der Speicherbereiche geringer, als der Erwartungswert für den Fall, in dem der Benutzer von Hand die Speicherbereiche in zwei unterschiedliche Zonen der Platten trennt. Da das System auf beide Partitionen zugreifen muss, ist eine höhere Zahl weiter entfernter Kopfbewegungen zu erwarten.

Auch wieder nicht verstanden. Wie muss das Betriebssystem die Platte adressieren, damit es sicher sein kann, außen auf der Platte zu landen? Das Ansteuern eines Zylinders gibt es schon seit vielen Jahren nicht mehr.

Tja, Dein Pech. Dann halt nicht.

osxnerd:

Schön worteich widersprochen (nach dem kurzen Motto: "Dagegen!" und "Du redest Unsinn"), ohne wenigstens eine Quelle zu nennen, wo ich (und andere) es aus anderem Munde als dem Deinigen nachlesen und vertiefen kann...