Fusion Drive oder große SSD?

[NeoAtti]

Hi,

So richtig geht es hier nicht voran.
Also fasse ich mal zusammen.

- Fusion Drive ist ein art HSM, welche aufgrund von Algorithmen und Statistiken entscheidet welche Daten wo abgelegt werden.
- wie in jedem HSM gibt es spezielle Situationen wo ein anderer Algorithmus ein "besseres" Ergebnis liefern könnte
- wie jedes HSM liefert es im gesamten ein wesentlich besseres Ergebnis als ein "manuelles HSM" über Laufwerke oder Ordner
- eine "reine SSD" Lösung ist im Zweifelsfall schneller
- eine "reine SDD" Lösung ist bei gleicher Kapazität wesentlich teurer.
- ein Fusion Drive hat eine höhere Ausfallwahrscheinlichkeit welche sich massgeblich dadurch ergibt das eine Festplatte eine MTBF von 250000 bis 1 mio Stunden hat, eine SSD aber i.d.R. von >2 mio Stunden. d.h. der Massgebliche Anteil der Wahrscheinlichkeit rührt von der mechanischen Festplatte. - Als Daumenregel nimmt man einfach an das sich ein FD wie eine herkömmliche Festplatte verhält
- eine SSD hat eine höhere MTBF als eine Festplatte
- die Kosten für ein FD sind im Vergleich zu einer gleich grossen SSD exorbitant:

2TB:

- 4 x Samsung 840 Basic 500GB = 283 * 4 = 1132 Euro

vs

- 1 x Samsung 840 Basic 120GB + Western Digital WD20EFRX Red 2TB = 90 + 100 Euro = 190 Euro

Das sind 942 Euro Differenz. (Alle Preise von Amazon)
Oder anders ausgedrückt man bekommt mit FD 6 mal so viel Kapazität für den selben Preis.

Atti

 

[Timbolomeus]

Hi, persönlich war ich nicht mit Fusion Drive zufrieden. Auch nach längerem Nutzen konnte ich die Geschwindigkeit der SSD nicht spüren. Vll wurde die SSD mit häufig genutzen Bildbibliotheken oder VM's verschwendet.
Leider konnte man (oder eher gesagt habe ich dazu nichts gefunden) nie einsehen, was denn nun auf der SSD geparkt wurde.

Meine Lösung war daher die Festplatten einfach zu trennen. OS / Programme etc. sind auf der SSD abgelegt und das gesamte usr Verzeichnis liegt dank Symbolic links auf der HDD. (So kann man auch nicht versehentlich beim Download o.ä. die SSD vollparken.)

Für aktuelle Bild-/Videobearbeitungsprojekte habe ich mir einen "Speedordner" erstellt, welcher logischerweise auf der SSD liegt.

Diese Lösung hat absolut einwandfrei funktioniert & ich musste keine hunderte Euros in eine SSD versenken...

 

[tomtom007]

...Meine Lösung war daher die Festplatten einfach zu trennen. OS / Programme etc. sind auf der SSD abgelegt und das gesamte usr Verzeichnis liegt dank Symbolic links auf der HDD. (So kann man auch nicht versehentlich beim Download o.ä. die SSD vollparken.)
...

Natürlich genau die Logik...
Meine USR Daten packe ich auf die langsame HDD weil das System da ja ständig zugreift.

Logisch wäre die SSD für alles und nur die Bilder/Musik/Video der HDD zuweisen. Aber da bin ich hier im Forum allein mit.

Ich persönlich mag aber die Symbolic Links nicht. Da gab es bei zu vielen "Kunden" Rechnern schon Probleme. Erst schlau mit Symbolic Links arbeiten und nachher wundern weil das System nicht mehr läuft und Daten versehentlich gelöscht wurden. Ich durfte dann später in Kleinarbeit dort wieder die Systeme hinbiegen.

 

[LXD]

Du kannst nicht Porsche fahren und nen Ford bezahlen. Du musst doch wissen was dir wichtiger ist.
Geld sparen oder die absolute Performance.
Hast du einmal SSD erlebt, wirst du nie wieder was anderes haben wollen. Hast du wenig Budget, ist zumindest Fusion Drive ne günstige alternative um einen enormen Performance Schub zu bekommen, aber sobald der Mac auf HDD-gelagerte Daten zugreifen muss, wirds halt was langsamer. Trotzdem freut man sich jedes mal wie schnell alles startet mit FD.
Starte ich aber meine Logic Pro mit zig GB von Samples trauere ich einer reinen SSD-Lösung hinterher.

 

[NeoAtti]

Natürlich genau die Logik...
Meine USR Daten packe ich auf die langsame HDD weil das System da ja ständig zugreift.

Logisch wäre die SSD für alles und nur die Bilder/Musik/Video der HDD zuweisen. Aber da bin ich hier im Forum allein mit.

Nein, bist du nicht!

Da die klassischen "Platzbeleger" seltenst wirklich verwendet werden (i.d.R. werden sie auf die Platte kopiert und liegen dann da die nächsten 3 Jahre rum), landen diese in einem HSM (so auch bei einem FD) letztendlich auf der HDD. Das gute (und der Sinn) ist es ja, das man sich NICHT darum kümmern muss und das HSM weiss dinge über die Dateien, die man sich im Traum nicht ausdenken könnte!

Atti

 

[carsten_h]

Logisch wäre die SSD für alles und nur die Bilder/Musik/Video der HDD zuweisen. Aber da bin ich hier im Forum allein mit.

Damit bist Du nicht alleine! So mache ich es. Und es klappt mit einer 128 GB SSD, einer 3TB für iTunes und einer 2TB für den Rest (iPhoto, Dokumente etc.) problemlos.

 

[primelinus]

habe auch os, programme und soundlibraries auf der ssd. der rest (projekte, mp3, bilder, videosetc.) ist auf der hdd. bei meinem anwenderprofil ist fusion drive nur am daten hin und her schaufeln... absolut sinnlos.

 

[GlennQuagmire]

primelinus, hast du ein fusion drive oder nur ssd?

wie meinst du das "bei deinem anwenderprofil".
ich befürchte nämlich für mich das gleiche.

getrennte zuweisung kommt mir eigentlich auch sinnvoller vor.
die bilddateien selbst können ja meinetwegen ruhig ein paar sekunden laden. wichtig ist ja der schnelle zugriff auf die bibliothek und itunes, bzw der programmstart.


mal nebenbei:
wenn ich eine thunderbolt ssd lösung als hungerstiller in betracht ziehe:
wie hoch ist da der geschwindigkeitsnachteil gegenüber einer intern verbauten ssd?

 

[NeoAtti]

bei meinem anwenderprofil ist fusion drive nur am daten hin und her schaufeln... absolut sinnlos.

Wie lange ist den das Fusion Drive in betrieb gewesen?

Ich würde annehmen, nicht besonders lange. FD schaufelt agressiv die Daten zwischen SSD und HDD , das ist korrekt - jedoch basiert das ganze auf Zugriffstatistiken, welche anfangs ja nicht vorhanden sind, bzw. sich ja sehr schnell ändern. Simpel ausgedrückt: Am "Anfang" haben alle Blöcke eine Zugriffstatistik von "0" - dann werden 7 Blöcke gelesen und diese 7 Blöcke haben dann in der Statistik das sie häufiger (also 1 mal) im vergleich zu allen anderen (0 mal) gelesen werden. Diese 7 Blöcke werden dann rel. zügig von der HDD auf die SSD gelegt. Jetzt werden andere Blöcke 2 mal gelesen. Nun haben diese eine Statistik von "2" und es ist somit - rein statistisch sinnvoller diese auf die SSD zu legen (und die "verdängen" dann erst die Blöcke mit "0" und dann mit "1".
Bei solchen kleinen Werten in der Zugriffsstatistik ändert sich ja sehr schnell was.

Jetzt kann man sich lange darüber streiten ob es sinnvoll ist so aggressiv wie Fusion die Blöcke ziwschen SSD und HDD zu "tauschen". Da das ganze mit niedriger Prio vonstatten geht (und nur dann gemacht wird, wenn der Rechner wenig/keine IOs macht) - gibt's eigentlich keinen Grund es weniger aggressiv zu machen.
Rein statistisch handelt OSX da vollkommen richtig und effektiver als es ein Mensch jemals tun könnte. Alleine am Anfang der Lebenszeit eines Fusion Drives ist das von dir beschrieben Verhalten zu beobachten. Und letztendlich tut das FD genau das was es soll ...
Wer lieber "manuelles Tiering" macht, kann das ja machen - effektiver ist das aber auf keinen Fall. (Zumindest wenn das Fusion Drive so funktioniert wie es soll ).

z.B. ist es aus Tiering-Gesichtspunkten totaler Blödsinn eine komplette Soundbibleothek auf "teuren Speicher" (also schnellen) zu legen. Soundfiles werden i.d.R. vergleichweise selten gelesen (halt wenn man sie hört - und wie oft macht man das pro Stunde, pro Tag?) - selbst wenn es Lieder gibt, die so oft gelesen werden das es sich für sie lohnt auf die SSD zu legen, für den grossteil gilt das dann trotzdem nicht.
Für die Verwaltung der Bibleothek reicht es, wenn die ständig gelesenen Daten (Metadaten) auf der SSD liegen - also die ersten und/oder letzten 128kb jeder Sounddatei. Das Abspielen kann geschieht dann von der HDD. - Und genau so arbeitet Fusion Drive - Teile von Dateien die oft gelesen werden können auf der SSD liegen und andere Teile die nicht so oft gelesen werden liegen auf der HDD. Speziell bei Media-Daten macht das auch absolut sinn.
Der Mensch handlet "nach gefühl", "nach geschmack" oder nach persönlichem befinden - Fusion Drive schaut auf die nackten Daten und entscheidet rein aufgrund von Zugriffststatistiken welche Daten auf die SSD kommen und welche auf die HDD.
Die reine Mathematik gibt Fusion recht.

Atti

 

[primelinus]

primelinus, hast du ein fusion drive oder nur ssd?

wie meinst du das "bei deinem anwenderprofil".
ich befürchte nämlich für mich das gleiche

der rechner greift täglich auf soundlibraries von 100-300 gb zu. mein damaliges fusion drive hatte eine ssd mit 128 gb und eine hdd mit 1 tb. nach eine paar tagen liefen die festplatten ständig. nach ca. drei monaten habe ich das fusion drive wieder getrennt.

 

[primelinus]

ca. 3 monate, bei einer täglichen benutzung von mindestens vier stunden.

 

[primelinus]

Teile von Dateien die oft gelesen werden können auf der SSD liegen und andere Teile die nicht so oft gelesen werden liegen auf der HD

was passiert, wenn die oft gelesenen teile die kapazität der ssd übersteigen?

 

[***elvis***]

...Teile von Dateien die oft gelesen werden können auf der SSD liegen und andere Teile die nicht so oft gelesen werden liegen auf der HDD...

Das klingt vom Prinzip gut, nur hätte auch z.B. alle Programme und die gesamte Library auf der SSD. Es gibt Programme die ich sehr selten nutze, ein, zwei, vielleicht dreimal im Jahr. Die würden dann warscheinlich auf die HDD geschoben. Und wenn ich sie dann mal brauch dauert es. Oder ist das FD so intelligent das es z.B. das OS, die Programme und die gesamte Libray, auch vom Benutzer auf der SSD behält?

 

[spaceman88]

was passiert, wenn die oft gelesenen teile die kapazität der ssd übersteigen?

Na es fällt quasi immer das am Wenigsten genutzte davon hinten runter auf die Festplatte.

 

[NeoAtti]

Hi,

Also dass das FD "ein paar Tage ständig" läuft, das glaube ich erst wenn ich es sehe. (ich denke damit ist gemeint das es Daten zwischen HDD und SSD "tauscht" - also IO's macht ohne das Apps auf die Platten zugreifen)

Das würde ja bedeuten das *ständig* andere Daten in der Zugriffsstatistik in den ersten 120 GB sind. Das ist natürlich denkbar, ist aber ein *äusserst* ungewöhnliches Zugriffsprofil. Um das mal zu Skizzieren: Das System liesst bestimmte 20 GB Daten immer wieder. (Wieso auch immer) und anschliessend liesst es anderen 20 GB Daten X-fach. Dann sind das 40 GB Daten die irgendwann auf der SSD landen (wenn sie da nicht sowieso schon sind).
Um diese Daten von der SSD zu "verdängen" müssten > 80GB andere Daten ÖFTERS gelesen werden als diese Daten. Selbst wenn das passiert (so was kann ja passieren, wenn man ein Projekt fertig hat und das nicht mehr benutzt und dafür ein anderes bearbeitet) - ist es ja auch vollkommen richtig. Das "alte" Projekt wandert auf die HDD und staubt vor sich hin und das "neue frische", aktive Projekt liegt auf der SSD. Perfekt!
Damit Fusion Drive ständig was zu tun hat, muss das ganze aber nicht im verlaufe von Tagen oder Stunden passieren, sondern "ständig". Es mag tatsächlich Anwendungsszenarien geben, wo so etwas passiert. Allerdings ist das wohl ehere ein Batchbetrieb auf Serverebene (aber selbst da werden Daten normal immer nur *einmal* gelesen. Ggf. zweimal aber das war es dann auch - wenn der Batch durch ist, wird die verarbeitete Datei nie wieder angefasst). Und für den Serverbetrieb ist Fusion auch nicht unbedingt gedacht.

Zu deiner Frage "was passiert, wenn die oft gelesenen teile die kapazität der ssd übersteigen?" - diese Frage stellt sich nicht, denn auf den 120 GB SSD liegen die Daten die "am häufigsten" benötigt werden.


Tiering automatismen basieren auf eine "Kostenrechnung" und zwar "Kosten" im Sinne von Zugriffszeiten:

Rein fiktive Werte:

- HDD = 5ms
- SSD = 1ms

Jeder Zugriff "kostet" eine "Währung". Ein HDD Zugriff 5ms und ein SSD Zugriff 1ms. In jeder Sekunde steht dem OS ein fixer "Betrag" zur Verfügung: 1000ms
Die Grundannahme ist: Die Anzahl der Zugriffe aus der Vergangenheit korreliert mit der Anzahl der Zugriffe in der Zukunft. (natürlich normiert auf den gleichen Zeitraum)
Wenn nun ein HDD Block 1 mal pro Tag gelesen wird, dann verursacht er "Kosten" von 5ms. Würde der Block auf SSD lieget, würden 4ms pro Zugriff gespart werden.
Ein Block der 2 mal pro Tag gelesen wird, verursacht Kosten von 10ms. usw.

Nehmen wir mal eine fiktive Blockstatistik (Zugriffe / Tag):

Block 1 - 9
Block 2 - 7
Block 3 - 12
Block 4 - 1
Block 5 - 1
Block 6 - 1
Block 7 - 3
Block 8 - 2
Block 9 - 17
Block 10- 5

Sagen wir die SSD kann nur 2 Blöcke enthalten, die anderen 8 Blöcke müssen auf die HDD.

Die Grundannahme vorausgesetzt ist das nun eine einfach "Optimierungsaufgabe" die Kosten so gering wie möglich zu halten. Nach ein wenig knobelei kommt man auf die Lösung: Mit Block 9 und 3 auf der SSD sind die Gesamtkosten am geringsten: 12 + 17 + 5*(9+7+1+1+1+3+2+5)

Ehy, was ist mit den Kosten die das "umschauffeln" verursacht? - Nun, die werden von der "nicht verbrauchten" Währung bezahlt. Pro Sekunde stehen 1000ms zur Verfügung, es ist aber kein "ansparen" erlaubt. d.h. wenn in einer Sekunde 500ms "verbraucht" werden, "verfallen" die übrigen 500ms. Diese 500ms werden dann verwendet um das umkopieren zu bezahlen.

Natürlich sind die Algorithmen ein bisschen ausgefuchster. Basieren aber alle auf der selben Idee. Fusion ist im Vergleich zu "Enterprise" HSM Lösungen (oder Tiering, ich sag immer HSM .. bin halt EMC geimpft) ist Fusion extrem aggressiv. (Auf Servern geschieht das Umkopieren in definierten "Lastarmen" Zeiten - 1mal pro Tag (das ist dann die "schnelle" Variante) oder 1 mal pro Woche (Wochenende).).

Was zeigt denn bei dir die Aktivitätsanzeige unter Festplattenaktivität unter Gelesen/Geschriebene Daten an? Und was sagt das Terminal bei "uptime"?

Atti

 

[CUC]

Mal eine etwas grundsätzlichere Frage:
Nach meinem Wissensstand (schon ein paar Monate alt), gibt es Anwendungen, für die sich SSDs (noch) überhaupt
nicht gut eignen - regelmäßiges Audiostreaming wie in Tonstudios z. B., was die Lebensdauer der Dinger erheblich verkürzen kann.

Das müsste Fusiondrives doch genauso betreffen?

 

[Tim01]

2TB:

- 4 x Samsung 840 Basic 500GB = 283 * 4 = 1132 Euro

vs

- 1 x Samsung 840 Basic 120GB + Western Digital WD20EFRX Red 2TB = 90 + 100 Euro = 190 Euro

Das sind 942 Euro Differenz. (Alle Preise von Amazon)
Oder anders ausgedrückt man bekommt mit FD 6 mal so viel Kapazität für den selben Preis.

Warum solch ein ungünstiges Beispiel? Wie wäre es mit der Samsung Evo 1TB für 515€ und deine WD für 100 Euro? Das wären 425€ mehr als dein 2.25TB FD Beispiel, aber mit Platz (3TB) und Geschwindigkeit (die 1TB Evo hat z.B. Turbowrite SLC-Cache 12 GB) ohne Ende.

Oder 1x Samsung Evo 500GB (leider nur 6GB Turbowrite Cache) für 300 Euro und deine WD für insgesamt 400€?

z.B. ist es aus Tiering-Gesichtspunkten totaler Blödsinn eine komplette Soundbibleothek auf "teuren Speicher" (also schnellen) zu legen. Soundfiles werden i.d.R. vergleichweise selten gelesen (halt wenn man sie hört - und wie oft macht man das pro Stunde, pro Tag?)

Tja, dann bin ich wohl blöd denn ich habe mir extra eine 500GB SSD geholt und habe ganz bewusst meine komplette Musiksammlung auf der SSD. Bei über 600 CDs dauert es wohl ein paar Jahre bis FD erkennt welche Lieder wir so oft hören dass sie auf der SSD landen.

Dazu sind die VMs alle auch der SSD. Obwohl ich die VMs selten nutze, will ich die bestmögliche Geschwindigkeit haben und nicht erst abwarten bis FD mir die Daten auch wirklich auf der SSD lässt.

Und genau so arbeitet Fusion Drive - Teile von Dateien die oft gelesen werden können auf der SSD liegen und andere Teile die nicht so oft gelesen werden liegen auf der HDD. Speziell bei Media-Daten macht das auch absolut sinn.

Hast du einen Beleg dafür dass nur Teile von Dateien auf die SSD geschrieben werden? Und wie groß sollen die Teile die man statistisch analysiert denn sein? Bei 128KB Größe und einem 1TB/128GB Laufwerk dürfte das einen gewaltigen statistischen Aufwand bedeuten.

Persönlich denke ich dass FD keine schlechte Idee ist, bei aktuellen (und hoffentlich noch fallenden) Preisen, zahle ich lieber 100€ mehr und richte mir das System so ein wie ich es für richtig halte.

 

[NeoAtti]

Hi,

Also das sich Anwendungen für SSD nicht eignen ist so erstmal verkehrt. Wenn da nicht irgendein krankes Timing von Schreibzugriffen im Programm geschieht (Windows 95 hatte sowas in der Art mal und da gab es Probleme wenn die CPUs zu schnell waren ;-) - oder wer kennt nicht die alten PC Spiele die auf neuen "AT" Rechnern viel zu schnell liefen ... ).
Was damit gemeint ist, das die Lebensdauer einer SSD halt "begrenzt" ist. Und zwar ist die Grenze die Anzahl der Schreibzugriffe auf eine Speicherzelle. Die grössten SSD "Mörder" sind übrigens Benchmarks
Aber richtig, je mehr man auf einer SSD schreibt, je schneller wird sie "Kaputt" gehen. (Wobei "Kaputt" hier etwas anders zu sehen ist, denn das hat nicht unbedingt was mit Datenverlust zu tun - am Ende der Lebensdauer einer SSD lassen sich keine Daten mehr schreiben. Lesen jedoch schon ).

Ja, man kann SSD "kaputt schreiben" - je mehr man schreibt, des so schneller gehen sie kaputt. Wie lange so eine SSD nun effektiv hält das ist echt schwer zu sagen wie lange eine SSD nun wirklich hält. Nix ist halt für die Ewigkeit. Und SSD schon gar nicht! - Dafür gibt es aber den SMART Status - der funktioniert bei SSD sehr gut und gibt eine gute "Vorraussage" wann eine SSD vermutlich "stirbt" (also nichtmehr schreibbar ist). So trifft es einen nicht plötzlich, wie das
meistens bei HDDs der Fall ist. (Und man kann die Daten ja noch lesen)

Im professionellen Einsatz muss man sich halt fragen ob eine SSD im vergleich zu einer HDD soviel Geld "bringt" wie sie in der Lebenszeit (sagen wir 1 Jahr) kostet.

Atti

 

[***elvis***]

@NeoAtti

Das klingt vom Prinzip gut, nur hätte auch z.B. alle Programme und die gesamte Library auf der SSD. Es gibt Programme die ich sehr selten nutze, ein, zwei, vielleicht dreimal im Jahr. Die würden dann warscheinlich auf die HDD geschoben. Und wenn ich sie dann mal brauch dauert es. Oder ist das FD so intelligent das es z.B. das OS, die Programme und die gesamte Libray, auch vom Benutzer auf der SSD behält?

 

[NeoAtti]

Hi,

Cool bleiben!

Warum solch ein ungünstiges Beispiel?

Es ist jedem freigestellt sich es sich für seine Zwecke schönzurechnen!
Wer dabei rausbekommt das SSD wesentlich günstiger als HDDs sind, dem kann man gratulieren!

Tja, dann bin ich wohl blöd denn ich habe mir extra eine 500GB SSD geholt und habe ganz bewusst meine komplette Musiksammlung auf der SSD. Bei über 600 CDs dauert es wohl ein paar Jahre bis FD erkennt welche Lieder wir so oft hören dass sie auf der SSD landen.

a) Ich habe dich und auch keinen anderen als Blöd bezeichnet. Ich habe ein verfahren beschrieben.

b) Nein, es wird keine Jahr und keine Monate dauern. Schon nach wenigen Stunden ist ein Fusion Drive "optimaler" als man es Manuell hinbekommen könnte.

Dazu sind die VMs alle auch der SSD. Obwohl ich die VMs selten nutze, will ich die bestmögliche Geschwindigkeit haben und nicht erst abwarten bis FD mir die Daten auch wirklich auf der SSD lässt.

Es ist vollkommen legitim sowas zu machen. Widerspricht auch keinem Fusion Drive. Wenn man für bestimmte Daten eine bestimmte performance Garantieren will, dann geht das NICHT mit einem Fusion Drive. Für solche Daten ist ein dedizierte SSD auf jedenfall das mittel der Wahl.

Hast du einen Beleg dafür dass nur Teile von Dateien auf die SSD geschrieben werden? Und wie groß sollen die Teile die man statistisch analysiert denn sein? Bei 128KB Größe und einem 1TB/128GB Laufwerk dürfte das einen gewaltigen statistischen Aufwand bedeuten.

Naja, der "gewaltige" Aufwand ist eine Tracking-Tabelle wo für jeden Block der gelesen wird ein Counter vorgehalten wird. Das ist nun wirklich weniger spannend. Was willst du für einen "Beleg"? - Fusion arbeitet auf Blockebene, wie sollte es anders sein?
Nur für dich hab ich jetzt mal ein wenig gesucht und habe in meinem 160GB Benutzerordner ein File gesucht was etwas grösser ist und auf der HDD liegt:

Das habe ich mal mit "dd" ausgelesen:

   12.44   4  0.05     0.00   0  0.00     0.00   0  0.00   3  4 93  0.68 0.71 0.65
   68.00   0  0.03   493.73 126 60.67     0.00   0  0.00   5  9 85  0.62 0.70 0.65
   68.00   0  0.03   509.96 125 62.42     0.00   0  0.00   4  9 87  0.62 0.70 0.65
   68.00   0  0.03   509.89 121 60.42     0.00   0  0.00   4  9 87  0.62 0.70 0.65
   68.00   0  0.03   509.78 101 50.24     0.00   0  0.00   4  8 88  0.65 0.70 0.65
          disk0           disk1           disk3       cpu     load average
    KB/t tps  MB/s     KB/t tps  MB/s     KB/t tps  MB/s  us sy id   1m   5m   15m
   68.00   0  0.03   509.81 131 65.38     0.00   0  0.00   4  9 87  0.65 0.70 0.65
   68.00   0  0.03   507.64 117 58.18     0.00   0  0.00   6  9 85  0.65 0.70 0.65
  107.36  22  2.30   509.14  89 44.44     0.00   0  0.00   7  9 84  0.60 0.69 0.65
   68.00   0  0.03   509.41  99 49.18     0.00   0  0.00   4  8 88  0.60 0.69 0.65
   68.00   0  0.03   509.81 117 58.16     0.00   0  0.00   6  9 85  0.55 0.68 0.64
   68.00   0  0.03   509.53 103 51.44     0.00   0  0.00   4  8 87  0.55 0.68 0.64
   68.00   0  0.03   509.96 125 62.42     0.00   0  0.00   5  9 86  0.55 0.68 0.64
   68.00   0  0.03   512.00 104 51.93     0.00   0  0.00   5  8 86  0.51 0.67 0.64
   14.73   7  0.11   509.88 121 60.18     0.00   0  0.00   5 10 86  0.51 0.67 0.64
   68.00   0  0.03   509.62 107 53.45     0.00   0  0.00   5  8 87  0.47 0.65 0.63
   25.67   6  0.15   509.40  98 48.93     0.00   0  0.00   4  8 88  0.47 0.65 0.63
   68.00   0  0.03   509.53 103 51.44     0.00   0  0.00   4  8 87  0.47 0.65 0.63
   68.00   0  0.03   505.20 113 55.68     0.00   0  0.00   4  9 87  0.51 0.66 0.64
   12.00   7  0.09   512.00  92 45.93     0.00   0  0.00   4  8 88  0.51 0.66 0.64
   68.00   0  0.03   509.81 117 58.17     0.00   0  0.00   3  9 88  0.63 0.68 0.64
   68.00   0  0.03   509.83 118 58.68     0.00   0  0.00   4  9 87  0.63 0.68 0.64
   21.00   2  0.04   509.92 123 61.17     0.00   0  0.00   5  9 85  0.63 0.68 0.64
   68.00   0  0.03   511.67  42 20.95     0.00   0  0.00   5  6 89  0.66 0.69 0.65
   68.00   0  0.03     0.00   0  0.00     0.00   0  0.00   4  4 92  0.66 0.69 0.65

disk0 ist die SSD, disk1 die HDD.

Wie man sieht wird das File ausschliesslich von der HDD gelesen.

Dann habe ich ein paar mal den ersten GB vom File von der Platte gelesen (auch mit dd und immer mit purge den cache geleert).
Nach ein paar durchläufen hat Fusion "angeschlagen" und hat eine weile umgeschaufelt (hat nicht lang dafür gebraucht keine Minute bis er zufrieden war). Dann sieht das lesen des ersten GB vom File so aus:

  27.00   2  0.05     0.00   0  0.00     0.00   0  0.00   4  4 92  1.25 1.20 0.91
   96.56 165 15.53     0.00   0  0.00     0.00   0  0.00   4  5 91  1.25 1.20 0.91
  377.47 975 359.56     0.00   0  0.00     0.00   0  0.00   4 12 84  1.25 1.20 0.91
  302.68 480 141.88     0.00   0  0.00     0.00   0  0.00   3  7 89  1.23 1.20 0.91
   40.27   7  0.29     0.00   0  0.00     0.00   0  0.00   4  4 92  1.23 1.20 0.91
   30.18   5  0.16     0.00   0  0.00     0.00   0  0.00   5  4 91  1.21 1.19 0.91
   22.00   2  0.04     0.00   0  0.00     0.00   0  0.00   5  5 90  1.21 1.19 0.91

Wie man sieht kommen wirklich *alle* Blöcke von der SSD!

Dann habe ich das ganze File (2,5GB) nochmal via dd gelesen (vor purge) und siehe da:

  58.44   9  0.51     0.00   0  0.00     0.00   0  0.00   4  4 92  0.78 1.05 0.89
   27.37 182  4.86     0.00   0  0.00     0.00   0  0.00   3  4 93  0.78 1.05 0.89
   87.43 2152 183.73     0.00   0  0.00     0.00   0  0.00   8 20 72  0.79 1.05 0.89
   60.38 2762 162.88     0.00   0  0.00     0.00   0  0.00   5 21 74  0.79 1.05 0.89
  148.69 1194 173.38   424.00   1  0.41     0.00   0  0.00   5 17 78  0.89 1.07 0.90
   45.20   5  0.22   142.67 364 50.69     0.00   0  0.00   3  8 88  0.89 1.07 0.90
   39.83  12  0.47    51.59 1130 56.93     0.00   0  0.00   6 11 82  0.89 1.07 0.90
   19.26  13  0.25   138.67 381 51.53     0.00   0  0.00   6  9 84  0.90 1.07 0.90
   16.67   9  0.15   105.42 550 56.64     0.00   0  0.00   4 10 86  0.90 1.07 0.90
   42.15   6  0.27   506.86 112 55.35     0.00   0  0.00   4  8 88  0.91 1.07 0.90
   66.00   1  0.06   149.79 331 48.35     0.00   0  0.00   4  8 88  0.91 1.07 0.90
          disk0           disk1           disk3       cpu     load average
    KB/t tps  MB/s     KB/t tps  MB/s     KB/t tps  MB/s  us sy id   1m   5m   15m
   19.84  22  0.43   508.82 100 49.88     0.00   0  0.00   3  8 88  0.91 1.07 0.90
   51.00   2  0.10   181.95 316 56.16     0.00   0  0.00   3  9 88  0.83 1.05 0.89
   68.00   0  0.03   512.00  92 45.93     0.00   0  0.00   4  8 89  0.83 1.05 0.89
   65.33   1  0.10   509.16 112 55.86     0.00   0  0.00   4  8 88  0.93 1.06 0.90
   64.80   2  0.16   156.06 377 57.46     0.00   0  0.00   3  9 88  0.93 1.06 0.90
   98.00   1  0.10   507.26 121 60.11     0.00   0  0.00   4  9 88  0.93 1.06 0.90
   53.60   2  0.13   511.00  64 31.89     0.00   0  0.00   3  6 91  1.01 1.08 0.91

Der erste GB kommt von der SSD, der Rest von der HDD!
Das ist genial, wie ich finde! - Ich kann auch sehen das wenn ich iTunes starte und in die Alben-Ansicht gehe, das die Metadaten der Files alle von der SSD gelesen werden. Wenn ich Musik abspiele, dann kommen diese Daten von der HDD. (Was natürlich nur ein paar kb/s sind).

Persönlich denke ich dass FD keine schlechte Idee ist, bei aktuellen (und hoffentlich noch fallenden) Preisen, zahle ich lieber 100€ mehr und richte mir das System so ein wie ich es für richtig halte.

Jeder sollte das System so machen wie er es für richtig hält. Keine Frage. Hat jemand was anderes behauptet?

Keine Frage ist eine reine SSD Lösung die, die zu bevorzugen ist. Allerdings ist speziell bei grossen Datenmengen das kein unerheblichen finanzielles Problem. (Zumal man sich schwer tut 3TB SSDs zu finden)
Wenn Geld keine Rolle spielt: Immer rein mit der SSD!

Atti