MacBook Pro Upgrade mid-2012

Ça y est. J’ai fini le processus (en trois heures et des brouettes).
Je n’ai pas encore tout testé, mais ça semble effectivement plus réactif. Je vais voir un peu tout ça.

Je reviens néanmoins un peu sur cette histoire de partitionnement.
Le problème, c’est que je suis un coupeur de cheveux en quatre.

Avec des HDD, je me posais ces questions :
Si un volume est créé par un redimensionnement, il va l’être :
– soit en début de disque
– soit en bout de disque.
Mais, alors
– s’il est fait en fin de disque, n’y a-t-il pas un risque pour que le programme de démarrage ait du mal à y retrouver ses petits à un moment donné.
– s’il est créé en début de disque, dans ce cas ce qui est déplacé ce sont les fameux fichiers qui sont censés être au tout début du disque, les plaçant... à la fin.

Mais j’imagine que de toute manière ces concepts, en admettant qu’ils aient d’ailleurs un sens pour un HDD, n’en ont plus avec un SSD.
 
Sinon, voici le détail de mon disque :

Bloc de code:
#:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            499.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

Je n'ai pas encore enclenché FileVault dans la mesure où j'attends que l'indexation se termine, mais tout à l'air en ordre.
 
J'ai fait une mise à jour Antidote et j'ai un truc qui m'inquiète : lorsque qu'il cherche des gestions d'applications à mettre à jour il me sort des doublons.
Exemple, pour FireFox :
Bloc de code:
/Volumes/Macintosh HD/Applications
/Applications
 
Salut doc

Ta table de partition est paaaarfaite ! Cesse de te préoccuper > tout est absolument comme il doit être : ta partition principale Macintosh HD encadrée par la petite partition EFI de 209 Mo (en-tête réglementaire d'une table de partition GUID) et la partition Recovery HD de 650 Mo. RAS.

Pour ce qui est des repartitionnements d'une partition existante, voici l'idée directrice : un repartitionnement opère toujours "par le bas", jamais "par le haut".

Car une partition, c'est un espace de blocs géré par un système de fichiers, dont les fichiers sont ancrés sur les tous premiers blocs de tête de la partition. Ces fichiers en gros permettent de transposer les écritures brutes des blocs en fichiers interprétables relevant d'un espace de répertoire = un volume monté. Or ces fichiers du système de fichiers constituent littéralement l'ancrage inamovible d'une partition : son "point origine" en quelque sorte (ou "départ logique"), puisque c'est par eux que sont gérées les écritures sur les blocs suivants de la partition.

Quand tu veux re-partitionner une partition, tu veux soustraire un certain nombre de blocs à la gestion du système de fichiers d'en-tête > il est donc logique que le système de fichiers reste inamoviblement à son ancrage "origine" > et que ce soit en queue de partition que s'opère la "résection" d'espace. Ce qui revient à dire qu'un certain nombre de blocs sont "soutraits" à la gestion du système de fichiers en place, lequel se trouve "rétréci" en ce qui concerne l'espace de blocs qu'il contrôle > et avec les blocs libérés de sa gestion, une nouvelle partition est créée. Càd. qu'un nouveau système de fichiers est généré sur les premiers blocs de cet espace libre, qui va gérer en lecture / écriture les blocs suivants qui ont été libérés. Blocs qui désormais constituent l'espace d'une partition, montable en volume [partition = espace de blocs géré par un système de fichiers d'en-tête ; espace libre = espace de blocs libérés d'un système de fichiers gestionnaire].
 
Merci pour ces précisions. ;)

Je sais que je m'inquiète un peu trop.

Par contre, j'ai un peu testé. C'est rapide, les applications sortent assez vite et quand on entre dans la session tout sort à toute vitesse, mais je mets tout de même une quarantaine de secondes à démarrer, je penser avoir besoin de moins.
 
  • J’aime
Réactions: melaure
J'ai lancé le cryptage. Ça a semblé assez rapide (1h ou 2), mais une autre opération s'est lancée ensuite : optimisation. Celle-là est beaucoup plus longue.
A ce propos, je n'ai pas encore lancé le TRIM.
 
Je suis très content d'avoir acheté en même temps quelques outils. Je pense que mon démontage-remontage était tout ce qu'il y a de propre, du coup.
 
Ça vaut vraiment le coup de l'activer, le TRIM (il y a un vrai risque de perte de données ?)
 
Nouveaux trucs bizarres :
- un mal de chien à transférer mes photos depuis mon iPhone : les photos sont bien transférés mais apparemment iPhoto ne le réalise pas et demande en boucle de les retransférer. A force de redémarrage du logiciel il semble ne plus le faire.
- handoff ne fonctionne plus.
 
Bon, récapitulons
- Clonage + Recovery HD faits
- FileVault fait
- Protection contre les mouvements brusques désactivée
- TRIM activé (vérifié dans le rapport système)

Disque :
Bloc de code:
 #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            499.1 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
 
Effectivement, c'est plus rapide (sans être presque instantané comme certains le prétendent).
- 30 secondes au lieu d'une bonne minute trente pour être sur le bureau.
- 45 secondes pour que tout soit opérationnel
- 3-4 secondes pour démarrer Safari
- idem pour Mail
- recherche spotlight quasi instantanée malgré FileVault

Je suis un peu déçu pour Power Nap, mais dans l'ensemble ça me change la vie.

J'attends les barrettes de RAM, peut-être cette semaine.
 
Et combien de temps entre le moment où tu touches le trackpad et le début du mouvement de souris ???
 
Par contre, j'ai toujours ce bug à la con, dans Photos : les photos sans cesse à réimporter.
 
Ça vaut vraiment le coup de l'activer, le TRIM (il y a un vrai risque de perte de données ?)
Oui, car cette est la garante d'un usage minutieux des cellules du ssd. En effet, celles-ci se dégradent avec le nombre de cycles de lecture/écriture. Pour faire simple, le trim est là pour coordonner tout cela et manager le tout pour éviter des cycles L/E inutiles ou redondants.
Au-delà de ça, même si l'on a encore que peu de recul, il y a fort à parier que la durée de vie des dites cellules soit bien suffisante pour un usage grand public...
 
@ Le Docteur

32813179.jpg
 
  • J’aime
Réactions: Sly54 et okeeb
C'est pas tellement le SSD qui m'inquiète, mais la possibilité d'un clonage foireux.
 
C'est pas tellement le SSD qui m'inquiète, mais la possibilité d'un clonage foireux.

Je ne dis pas que c'est impossible, mais en plus de 10 ans de CCC, je n'ai pas eu de problème, et je les compte presque en centaines les clonages ...
 
  • J’aime
Réactions: litobar71 et okeeb
C'est pas tellement le SSD qui m'inquiète, mais la possibilité d'un clonage foireux.

Si tu y tiens, je peux te passer une commande dans le «Terminal» appelant l'utilitaire ®Apple[100%] asr (apple_software_restore) qui pourrait te cloner en mode "blocs" le volume de ton HDD originel (pour peu qu'il soit attachable à ton Mac en USB) dans le volume de ton SSD (qui serait effacé pour l'occasion). Pour une telle opération impliquant le démontage après vérification du volume "source" et du volume "destination", il faut donc un Système démarré tiers, qui pourrait être celui de ton clone en l'occurrence.

Un clonage asr clone y compris la partition Recovery HD si elle est présente en collatéral sur le disque de la "source" > ce procédé surpuissant diffère du clonage «Carbon Copy Cloner» car ce dernier logiciel effectue une recopie en mode "fichiers" et pas en mode "blocs".

Quoique parfaitement averti de la perfection radicale du procédé asr > je ne l'emploie jamais en pratique mais à l'instar de melaure j'utilise toujours «Carbon Copy Cloner» auquel je suis fidèle depuis l'âge héroïque des débuts d'OS X. Pour tout dire : je fais entièrement confiance à l'exécutable de recopie mis au point par Mike Bombich car, d'expérience personnelle, je n'ai jamais eu par lui de clone non-démarrable et je n'ai pas non plus constaté de pertes de fichiers non plus que de permissions.

«Carbon Copy Cloner» se borne à exclure régulièrement de sa tâche de clonage des fichiers de cache ou de log de la "source" qui ne feraient pas sens sur la "destination" > mais il reconstruit toujours en fin de clonage un cache-Système de démarrage impeccable qui permet au Système cloné d'être parfaitement démarrable.
 
Bon midi,

Cela fait maintenant "jolie lurette" que mon système est un arrière-arrière-arrière-etc..petit-fils de mon premier clone asr suivi par des Carbon Copy Cloner's et ceci roule correctement.

Je n'ai eu qu'à remettre de temps à autre partage et permission du HDD/SSD en lecture et écriture pour ma session admin principale
mais jamais pour la seconde admin ni l'autre standard, je suis très très enthousiaste lorsque je lance CCC pour un clonage partiel ou total ou un rétro-clonage car jamais de soucis jusqu'à présent, une totale confiance, merci à Mike Bombich et au prix très décent du logiciel vu les services rendus.

Voilà voiloù.. ..

NB: j'allais oublier une composante intéressante ➞ la rapidité

Je mets à ce logiciel  càd le max.
 
Dernière édition: