# Mac plus lent depuis Fusion Drive



## djimmy.l (15 Février 2015)

Salut tout le monde,

Donc tout d'abord, j'avais un compte sur le forum mais apparemment il a été supprimé, mais bon c'est pas trop grave, je ne sais pas si je dois faire une présentation avant de poster, n'hésitez pas à me le dire si c'est le cas 

Donc, mon problème, j'ai un mbp 13" de mi-2010, entrée de game 2.4ghz 4go de base et 250go de *HDD*, la base quoi, il y'a un an je suis passé sur un *SSD* de 250go, j'ai vu directement la difference une bete de guerre, mais j'ai trouvé que 250go était insuffisant par rapport à mes besoins de l'époque, j'ai donc trouvé une alternative entre un espace de stockage conséquent et la puissance d'un *SSD*, vous l'avez compris, je suis passé sur du *FusionDrive* en enlevant le lecteur cd pour y mettre un *HDD* (1to - 5400trs/mn), au début, il tournait pas trop mal mais avec le temps je trouve que la puissance de mon mac s'est dégradé, je suis donc passé à 8go de RAM ainsi qu'une restauration complete, aucun changement, avez vous une idée du pourquoi du comment ?

- Le *HDD* est il trop gros ?
- Pensez vous que si je supprime le *FD* et je ne laisse que le *SSD* et garde le hdd en externe il sera plus rapide ?
- une commande à faire en particulier ?

Bref je prends tout ce qui peut m'aider je vous remercie !


----------



## djimmy.l (16 Février 2015)

Bon bah desolé de devoir répondre apparement je ne peux pas edit pour poser ma nouvelle question/suggestion...
Et si plutot que de tout redémonter, je laissais le systeme sur le ssd et je garde le hdd de 1to dans mon mac et je fais ma time machine directement dessus en plus de gerer moi meme ce qu'il y'a dedans, en soit mon mac sera aussi rapide que s'il était en SSD seul et mon hdd en externe non ?
Tks !


----------



## djimmy.l (18 Février 2015)

Up.


----------



## macomaniac (18 Février 2015)

Élucubration macomaniaque à prendre comme exercice spéculatif​
Salut *djimmy*.

Je veux bien te faire un bout de conversation sur le sujet.

Je sais que toute une "_réclame_" tapageuse a été faite en son temps concernant le procédé du «Fusion Drive» censé «_réunir le meilleur des deux mondes : la vitesse d'un SSD et le volume d'un HDD_» (_sic_).

Je n'ai jamais adhéré personnellement à cette présentation flatteuse.

Dans les faits, un «Fusion Drive» consiste à plaquer sur chaque Disque Physique Réel l'artefact primaire d'une couche logicielle : celle d'un Disque Physique Virtuel. Ces 2 Disques Physiques Virtuels se trouvent alors solidarisés dans une instance de partage : une Famille de Volumes Logiques unique. En fonction des paramètres de cette dernière (_nom_, _format_, _chiffrement_), un Volume Logique unique se trouve rejeté en 3è et dernière instance, qui, pour l'utilisateur, affecte toutes les caractéristiques du Volume Standard d'un disque physique unique.

Ce Volume Logique unique a pour taille la somme des espaces-disques des 2 Disques Physiques Réels (moins une 'tare logicielle' non négligeable au yeux d'un esprit sourcilleux). Quelle est alors la vitesse exécutive des processus de lecture/écriture sur ce Volume Logique? La "_Légende Urbaine_" veut que les _outils_ et les _objets_ les plus fréquemment utilisés seraient affectés au seul support _le plus rapide_ de l'atttelage (le SSD), les _outils_ et les _objets_ les moins fréquemment employés étant stockés sur le support _le plus lent_ (le HDD). En l'absence d'une application spécifique qui gèrerait distributivement l'allocation des ressources à tel support physique plutôt qu'à tel autre, absolument *rien* dans la _structure formelle_ d'un Groupe de Volumes Logiques n'implique _sui generis_ une pareille *optimisation des ressources*. *Rien* dans la définition de l'instance médiatrice : Famille de Volumes Logiques, à partir des seuls paramètres de _nom_, _format_, _chiffrement_ de laquelle se trouve rejeté un Volume Logique unique, n'existe qui constituerait un logiciel de *pilotage * affectant *rétro-activement * à tel ou tel disque physique réel une redistribution *dynamique *des ressources en fonction de leur fréquence temporelle d'usage.

Comment cela se pourrait-il? Là où quelque chose est écrit, c'est écrit et ça ne se ballade pas librement d'un support d'écriture à un autre. Je ne vois pas comment il pourrait y avoir _nomadisme_ des écritures. Ce qui paraît plausible est un _état de grâce_ des commencements : le SSD étant un support nettement plus rapide en écriture, il est envisageable qu'_à l'origine_, cette "facilité" d'écriture le "pousse en avant" comme support primaire soit de l'installation de l'OS, soit de la suite des fichiers. Jusqu'à saturation, où les écritures se reporteraient sur le support vacant. Auquel cas, les écritures les plus récentes seraient automatiquement les plus lentes à l'usage.

Nulle part dans l'organisation logique d'un Groupe de Volumes Logiques, je ne vois une _instance d'arbitrage _qui imposerait une ré-écriture de ressources plus récentes, parce qu'éventuellement plus employées, au support le plus rapide, avec leur effacement du support le plus lent. Dès que les deux Disques Physiques Réels se trouvent recouverts de la couche logicielle d'un Disque Physique Virtuel, ils sont logiquement égaux, et c'est seulement la _facilité à écrire_ qui peut diriger aveuglément les processus vers le support le plus rapide. Mais comme je l'ai suggéré, cette _facilité_ _aveugle _doit alors se faire sentir _dès l'origine_ pour charger le support le plus rapide (SSD) jusqu'à saturation, et ensuite reporter sur le support le plus lent (HDD) la suite des écritures. Forcément alors, l'OS s'installe sur le SSD avec les contenus qui ont intéressé l'_Âge d'Or du Commencement_. Atteint la limite _historique _de stockage du SSD, tout doit se reporter sur le HDD pour instaurer l'_Âge de Fer du Consécutif_. 

Si mon imagination analytique n'erre pas et que le seul de critère d'attribution au support le plus rapide (SSD) soit la _facilité d'écriture_ *aussi longtemps qu'il y ait de la place libre*, alors un utilisateur qui ne ferait jamais le ménage des contenus stockés _à partir du commencement_, mais au contraire _thésauriserait _indéfiniment des contenus sans jamais rien supprimer, à un moment *critique* donné subirait l'effet d'un SDD bourré et le report de toutes les écritures additionnelles au support le plus lent : le HDD. Son impression serait alors nécessairement que son Mac *se met à ralentir* relativement à l'exploitation des données les plus récentes, forcément les plus familières, comparativement à l'euphorie de l'origine, où le seul SSD offrant une espace vacant se trouvait concerné par les écritures - quelles qu'elles soient.

S'il en était ainsi, la capacité d'un «Fusion Drive» à gérer indéfiniment l'allocation des ressources écrites en fonction de l'usage prioritaire ne serait qu'une _illusion temporelle_ transformée en "_Légende Urbaine_" - absolument rien dans l'édifice formel d'un Groupe de Volumes Logiques : CoreStorage n'impliquant un programme de _transfert dynamique des écritures_ du support le plus lent au support le plus rapide en fonction de la fréquence temporelle d'usage ; mais, l'effet accumulatif de l'usage, après saturation du SSD privilégié _originellement _par la _facilité d'écriture_ à son disque, reporterait *tout* ce qui s'ensuit en teme d'usage sur le disque le plus lent (HDD) car seul vacant.


Si cette analyse n'était pas complètement _errante_, alors il serait clair qu'un «Fusion Drive» serait une _dangereuse illusion_. _Illusion_, de croire qu'un dispositif formel statique équivaille à une _programme de réallocation dynamique des écritures en fonction de la fréquence temporelle de lecture_. _Dangereuse_, si le point de transfert des écritures au support le plus lent était déterminé par la saturation du support le plus rapide. Car un disque saturé en écriture est susceptible de planter. Le paradoxe serait alors que le *disque le plus faible* dans l'attelage d'un «Fusion Drive» ne serait pas, ainsi qu'on l'imagine, le HDD (car disque en rotation susceptible d'une défaillance mécanique classique), mais de façon surprenante le SDD (car disque utilisé en priorité en vertu d'un critère de _facilité d''écriture _jusqu'au point de saturation, avant transfert d'écritures au disque le plus lent). Un «Fusion Drive» ne ferait donc pas dépendre le sort de l'attelage du disque le plus faible physiquement (le HDD), mais du disque le plus faible logiquement (le SSD).


----------



## djimmy.l (18 Février 2015)

Super réponse @macomaniac très complete !
Je te remercie, je me disais bien aussi que mon SSD devait être blindé mais je pensais réellement que le FD déplaçait les données... Ca peut être pratique pour une personne qui veut pas trop se prendre la tête mais je pense que je peux gérer tout ça "à la main" j'aurais la totale maitrise des disques !

Bon j'ai déjà sauvegarder mes fichiers les plus utiles, il me reste plus qu'à démonter le FD, c'est pas une partie de plaisir apparemment...

Ce que j'ai décidé de faire du coup :
   - Démonter le FD.
   - Laisser les deux disques dans mon MBP histoire de ne pas me trimballer un disque dur externe a chaque fois que je prends mon ordi.
   - faire une time machine "interne" (on sait jamais).

Ca peut le faire selon vous ?


----------



## subsole (18 Février 2015)

Bonjour 
Je ne ferais pas un TM sur le DD interne, en cas de problème, (vol, fausse manipulation, etc.), tu perds tout .
Fais une  ™ ou un clone sur un DD externe.


----------



## djimmy.l (18 Février 2015)

C'est vrai que c'est pas très utile pour le coup... Bon bah en tout cas merci pour vos réponses les gars


----------



## macomaniac (18 Février 2015)

J'opterais comme *subsole*.

Je supprimerais mon «Fusion Drive» (ce qui ne se peut que par la destruction du Groupe de Volumes Logiques : CoreStorage, et donc du Volume Logique qui en dépend, avant libération de 2 volumes standards vierges, chacun référé à son disque physique --> d'où nécessité d'une sauvegarde au préalable des contenus du Volume Logique global).

Je ré-installerais l'OS sur le SSD, mais pour ce qui est de mon "espace domiciliaire" (le compte d'utilisateur), au cas où il serait hypertrophié en "contenus" divers au point de peser plus de 200 Go, alors soit je le copierais en bloc sur mon HDD, et je lierais mon identité d'utilisateur définie dans l'OS du SSD à ce dossier comme dossier de départ d'utilisateur (faisable aisément dans le panneau d'_options avancées_ des _Préférences Systèmes/Utilisateurs et Groupes_) ; soit je déporterais sur le HDD les très grosses bibliothèques constituant des blocs de contenus («iTunes» / «iPhotos») si c'était le cas, en y liant ces applications pour mon usage de session. Et tout ce qui pèse sans être dépendant d'une bibliothèque : dossier de vidéos imposant, machines virtuelles etc. --> tout ce bazar, par défaut sur le HDD. Bref, je m'inspirerais du principe général : OS et outils sur le SSD / Réserve de contenus sur le HDD. Question "ressources perso", je privilégierais pour le SSD, _à la mimine_, ce à quoi vraiment je recours le plus : genre telle machine virtuelle qui me sert quotidiennement etc, histoire d'avoir un privilège de vitesse exécutive d'une utilité réelle.

Pour ce qui est des sauvegardes, je ferais ça sur des supports externes (DDE) en réservant disons : un volume à un clone démarrable du SSD seul ; un volume à une sauvegarde «TimeMachine» du même ; et un volume à une copie-miroir (à mettre à jour) des données du HDD.​
Pour ce qui est des détails de la manœuvre (_Clean Install_ puis ré-importation, ou rétro-clonage /ré-installation depuis une sauvegarde TimeMachine avec exclusions ; un ou plusieurs DDE etc.) - à réfléchir posément.


----------



## jcezanna54 (16 Mai 2015)

macomaniac a dit:


> ​ il pourrait y avoir _nomadisme_ des écritures.
> , parce qu'éventuellement plus employées, au support le plus rapide,



Bonjour,
Tout d'abord je précise que cette histoire de fusion drive, me paraît aussi fumeuse le rapport gain/prix ne me paraît pas évident.
Par goût, je n'aime pas les solutions alambiqués car elles sont toujours moins robustes sous un verni d'intelligence usurpé.

J'attire simplement l'attention de macomaniac sur le fait que l'attribution de données (je n'ai pas écrit fichiers, il peut s'agir de blocs disque) pourrait être fait d'une part comme indiqué sur la fréquence d'utilisation mais aussi sur la dernière utilisation. Si vous avec utilisé un bloc de données récemment, il y a une bonne probabilités que vous le rappeliez prochainement.
Enfin le nomadisme des écriture peut se faire suivant le fonctionnement bien connu du cache unix : quand le processeur n'a rien à faire (c'est le cas à 90% sur un PC), il écrit sur le disque, avec pour cause de mémoire volatile, une écriture périodique globale.
Il me semble que ce mécanisme peut aussi être inclus et adapté dans Fusion drive mais je n'ai pas "visité" les internes...
Cordialement,


----------



## zenelae (20 Mai 2015)

Hello, je suis de l'avis de mes confrères, aujourd'hui un Fusion Drive est une fumerie. Lors de sa sortie, j'en a créé un sur mon hackintosh pour tester, je n'ai pas trouver de réel avantage.

Tu serais gagnant de faire une install de mac os X sur ton SSD et de garder ton second HDD en stockage uniquement. 

Tu optimiseras ainsi les perf de ton SSD.


----------

