Fragen zu SSD-Wechsel und Fusion-Drive in Mac mini

[Rastafari]

Ich kann mir gerade nicht so vorstellen, welche Dateien ich immer wieder verarbeiten soll

Die Systemsoftware selbst kann das aber. Darüber wird exakt Buch geführt, und das nicht aus Jux und Tollerei.

der komplette User-Libraray-Ordner / MS-Ordner - könnte man per Sym-Link auch auf die SSD legen

Was alberneres könnte man kaum tun. Ausser sich direkt ins Knie zu schiessen.
Damit addieren sich die Zugriffszeiten beider Medien, statt sich zu verringern. 'oppla.

 

[Husky]

Aber ich verstehe schon, warum Du das so machst / machen wollen würdest, aber mich reizt ein FD so gar nicht. Ich habe das bisher an 2 Rechnern so gemacht und bin sowohl von der Performance als auch vom Handling völlig überzeugt.

Ich bin ja in der ´Findungsphase´ und eben weil ich unsicher bin, habe ich den Thread hier eröffnet. Mittlerweile ist meine Tendenz so, daß ich wohl verfahren werde, wie in meinem letzten Posting angedeutet. Also Arbeiten mit der 500er SSD only. Time Machine Backup auf der internen HDD. Eventuell noch eine Partition für Daten auf der internen HDD.

Noch unsicher bin ich mir von der Strategie, was die komplette Sicherung meiner beiden Mac mini inklusive aller Daten angeht: http://www.apfeltalk.de/forum/datensicherung-mac-mini-t452402.html#post4236608

 

[Zonk]

Die Systemsoftware selbst kann das aber. Darüber wird exakt Buch geführt, und das nicht aus Jux und Tollerei.


Was alberneres könnte man kaum tun. Ausser sich direkt ins Knie zu schiessen.
Damit addieren sich die Zugriffszeiten beider Medien, statt sich zu verringern. 'oppla.

Schieß Dir hin wo Du willst, ein Fehler ist das möglicherweise nicht.

Wenn Du eine Datei mit mehreren hundert MB oder GB lädst, spielen die addierten Zugriffszeiten im ms-Bereich überhaupt keine Geige. Das geht schneller als Du abdrücken kannst. Selbst wenn ich mehrere hundert "kleiner" Dateien bearbeiten will, habe ich bisher kein Delay bemerkt, wobei hierbei der Symlink ja auch auf den übergeordneten Ordner gelegt wird. Ich könnte mir vorstellen, dass die tolle Protokollierung (und damit ständiges Lesen und Beschreiben der Systemplatte) der Systemsoftware, welche Datei ich wann, wie oft und warum geladen, bearbeitet oder sonst was getan habe deutlich mehr Ressourcen benötigt, als das Lesen eines Symlinks.

 

[Rastafari]

Wenn Du eine Datei mit mehreren hundert MB oder GB lädst, spielen die addierten Zugriffszeiten im ms-Bereich überhaupt keine Geige.

Wieviele davon findest du denn im typischen Library-Ordner? Hm?

wobei hierbei der Symlink ja auch auf den übergeordneten Ordner gelegt wird.

Und das soll inwiefern einen Unterschied machen?

Ich könnte mir vorstellen, dass die tolle Protokollierung (und damit ständiges Lesen und Beschreiben der Systemplatte) der Systemsoftware, welche Datei ich wann, wie oft und warum geladen, bearbeitet oder sonst was getan habe deutlich mehr Ressourcen benötigt, als das Lesen eines Symlinks.

Erstens interessiert nur das wann und das wie oft.
Zweitens wird das sowieso getan, völlig egal ob du Teile auslagerst oder nicht.
Drittens liegt die mittlere Zeit zur Vorbereitung der Auflösung eines symbolischen Links bei 1-1,5 ms. So lange dauert es, eine gewöhnlich abgelegte textuelle Referenz auch nur zu parsen, erst danach folgt dazu noch die eigentliche Auflösung des ermittelten Pfades. Das schliesslich dauert nochmal so lange wie das finden des Symlinks selbst.
Vergleiche:

time for ((i=0;i<10000;i++)); do : ; done;
time for ((i=0;i<10000;i++)); do readlink /var > /dev/null ; done;

Verstanden?
Merke: Symlinks machen die Dateiorganisation zwar flexibel, aber ganz bestimmt nicht flott.
Statt den Inhalt von nur einer Datei einzulesen, musst du jedes mal zwei davon öffnen und lesen, sobald ein Symlink ins Spiel kommt.
Dagegen ist der Hotfile-Mechanismus nur ein leiser Furz im Sturm.