10.13 High Sierra TrimForce ou TrimEnabler ? + étrangeté

[Membre supprimé 1060554]

La phase boot.efi n'est donc absolument pas impactée : celle où le boot_loader charge le kernel en RAM > puis lui injecte les extensions en tableau --> que l'extension qui gère le TRIM soit présente ou absente du tableau ne change absolument rien. Ce n'est donc pas un problème à l'injection.

J'avais dû mal à concevoir une explication à ce niveau-là et ma conjecture (spéculative) d'une extension (celle du TRIM) qui serait restée hors-cache et qui aurait dû être injectée isolément > ce afin d'expliquer un délai supplémentaire dans le temps d'opération du boot.efi --> doit être complètement abandonnée.

C'est donc dans la phase opératoire correspondant à l'affichage de la barre horizontale que la différence de délai de 15" intervient. Mais j'ai l'impression de tomber de Charybde en Scylla en ce qui concerne les problèmes à concevoir la « raison des effets ».

Car manifestement la barre horizontale désigne la phase globale de "chargement du Système". Notion confuse s'il en est, puisque 2 séquences sans commune mesure se succèdent pendant ce fameux "chargement du Système" --> la séquence primaire "intra-kernel" et la séquence secondaire "extra-kernel".

• la séquence primaire "intra-kernel" désigne la phase où, le kernel devenu un moteur autonome avec toutes ses extensions, prend en charge les structures additionnelles fondamentales qui constituent le « Système » (BSD). À l'issue de cette phase > le kernel est le noyau opérateur d'un « Système».

• cette opération accomplie > le kernel exécute le programme de launchd > càd. lance le Serveur qui va initialiser les services de l'OS à proprement parler. On est là dans une séquence "extra-kernel". launchd, par exemple, va mettre en route le "service d'annuaire" (Open Directory) - soit toutes les routines logicielles qui font "tourner" l'OS. Toutes ces tâches vont jusqu'au moment d'ouvrir une session graphique d'utilisateur.

Lorsqu'il n'y avait pas à l'écran de boot de barre de chargement qui crée la confusion --> on voyait une roue crantée giratoire pendant toute la séquence primaire "intra-kernel" --> ce qui permettait de s'apercevoir que la prise en charge du Système BSD par le kernel est un opération de grande envergure, vu le temps que ça prenait. À un moment donné --> cette roue crantée disparaissait > il y avait un saut d'écran --> ce qui signifiait clairement que le processus extra-kernel de launchd était en cours. Càd. que les services de l'OS étaient en train d'être démarrés. La distinction des séquences était claire, graphiquement parlant.

Je trouve qu'à présent l'artefact d'une barre de progression continue dissimule la différence fondamentale entre séquence intra-kernel et séquence extra-kernel : prise en charge du Système et initialisation de l'OS.

Malgré tout > quand tu dis -->

Clairement à la fin de la barre de progression. Il y a un petit arrêt et à partir de cet arrêt deux scénarii

- je conjecturerais (spéculativement) que l'arrêt en question consiste dans le passage de la séquence intra-kernel (Système) à la séquence extra-kernel (launchd).

Sans l'extension du TRIM chargée --> "chargement rapide" jusqu'à l'écran de connexion ; avec l'extension du TRIM chargée --> "reprise lente" jusqu'à l'écran de connexion. Il est clair que ce qui est pointé là est l'activité extra-kernel du Serveur launchd : launchd exécute vite son service d'initialisation sans le TRIM > plus lentement avec le TRIM.

Ce constat (empirique) me pose un problème pour en rendre raison théoriquement. Car launchd n'a rien à voir avec le TRIM ! Le TRIM est l'affaire du kernel, une affaire intra-kernel > pas l'affaire de launchd, une affaire extra-kernel. Pourquoi launchd se trouve-t-il ralenti dans son activité de service par un facteur qui n'est absolument pas de son ressort mais de celui du kernel ?

Je vais avancer une conjecture (spéculative) : si on admet que le kernel attende (temporellement) la fin du chargement du Système -BSD pour lancer l'opération du TRIM de l'extension qui a été injectée précédemment --> alors on peut concevoir une stase entre la fin de la séquence intra-kernel et le démarrage de launchd. Ma conjecture me satisfait modérément : elle consiste à dire --> le lancement de launchd serait différé. Après quoi l'exécution du service de launchd serait aussi rapide en soi. Si j'en suis modérément satisfait --> c'est que je ne suis pas sûr que ça "colle" exactement avec l'observation : "reprise lente".

 

[Le docteur]

Il y a encore un saut d'écran pour ce que je vois : un changement net de couleur. Et clairement ça apparaît avant.
Alors histoire de compliquer encore un peu la chose (ou pas)
1 - avec le Trim issu de la commande TrimForce j'avais un arrêt un peu long disons au deux tiers du chargement (ou un peu plus) et après cet arrêt d'un coup changement de couleur et chargement rapide.
2 - avec le Trim issu de TrimEnabler c'est devenu un ralentissement généralisé au moment où j'avais arrêt (la barre avance, mais très lentement), puis écran qui change de couleur et chargement rapide
3 - depuis que j'ai passé la commande que tu m'avais conseillé si j'avais FileVault (et que j'ai passé connement sans réaliser que je l'avais à un moment dégagé — pourtant j'ai l'écran de démarrage pour me le rappeler tous les jours, bref !) on dirait que le Trim enclenché par TrimForce se comporte comme celui activé par TrimEnabler (ralentissement au lieu d'un arrêt puis d'un reprise).

Ca ne pourrait pas être la fin de l'intra-kernel (avec un check du disque qui ne reconnaîtrait pas un SSD "Apple") qui bloque étant donné que le changement de couleur de l'écran intervient après.
Au temps pour moi ! C'est ce que tu proposais (je réponds en te lisant). Ca y ressemble.
En fait je t'ai induit en erreur avec l'histoire de "reprise lente". Je pense que ton explication tient. Mais par contre je ne comprends pas les scénarios 2 et 3 que je décris plus haut et qui effectivement ressemble plus à un ralentissement généralisé au point qui ressemble plus à un blocage dans le scénario 1.

 

[Membre supprimé 1060554]

Ca ne pourrait pas être la fin de l'intra-kernel

D'accord : on va dire qu'avec l'OS High Sierra --> l'espace de la barre horizontale qui marque le chargement logiciel d'ensemble se laisse décomposer en 2 parties :

• la 1ère partie : le processus intra-kernel --> le kernel précédemment activé par le boot.efi avec injection de sa panoplie de pilotes > devient le moteur d'un Système fondamental en prenant en charge le sous-système BSD qui apporte les compléments de programmation. Intra-kernel parce qu'il s'agit du déploiement d'un « espace du kernel » en tant que Système. On dira que cette prise en charge va jusqu'aux deux-tiers environ de la barre.

• la 2è partie : le processus extra-kernel --> le kernel devenu le cœur d'un Système Étendu > exécute un programme de type "Serveur" qui va initialiser toute une série de sous-services : le Serveur « launchd » > qui va lancer toute la série des sous-services de l'OS proprement dit. On dira que cette activité d'« INITialisation » démarre après le saut du dernier tiers et le changement de colorisation de l'écran --> vers les deux-tiers de la barre jusqu'à la fin. À la fin : c'est l'interface graphique qui intervient.

Que ce soit la commande trimforce d'Apple > que ce soit la nouvelle version de Trim Enabler : les 2 procédés consistent à faire injecter une kext (extension) dans le kernel pendant la phase boot.efi (=  seule). Ce que tu rapportes montre que le ralentissement induit par la kext additionnelle --> n'est pas un ralentissement à l'injection dans le kernel par le boot.efi ( seule) > mais un ralentissement pendant le processus intra-kernel proprement : la phase de constitution du Système Opérateur.

Ce qui apporte un éclairage "épistémologique" (si je puis dire) : les pilotes qui sont injectés au kernel dans la phase boot.efi ( seule) ... ne pilotent rien du tout dans cette phase. Il s'agirait d'une annexion logique au kernel qui n'a encore nul caractère opératoire. C'est pendant le processus intra-kernel : le processus d'« Extension-Système » du kernel (d'extension au sous-système BSD) --> que les pilotes injectés précédemment prendraient effet. Alternative : sinon tous les pilotes > du moins le pilote spécifique du TRIM sur SSD tiers. Ce serait dans cette phase intra-kernel --> que le kernel chargé en RAM prendrait en charge les disques - une tâche apparemment "compliquée" et ralentie par l'opération du TRIM.

Une fois le kernel devenu le moteur d'un Système Étendu --> le processus extra-kernel de launchd s'exécuterait comme d'habitude.

----------

- curieusement (en ce qui me concerne : SSD Crucial et MacBook Pro 2011 - version developper beta de High Sierra 10.13.4 apfs > TRIM assuré par l'extension Apple) > en terme disons de vitesse de boot -->

• je n'ai rien à reprocher à la séquence boot.efi ( seule) : rapide.

• le processus intra-kernel (deux premiers tiers) se déroule avec une progressivité continue : rien de décoiffant comme vitesse mais disons un rythme soutenu qui donne au spectateur l'impression d'un chargement bien rythmé (en gros : comme de regarder une course de chevaux trotteurs --> ça ne galope pas, mais c'est régulièrement rythmé).

• par contre le processus extra-kernel de launchd (dernier tiers) est chez moi une vraie misère --> une vraie baisse de régime de la mise en service par rapport au travail du kernel proprement dit. Ce qui donne au spectateur (= moi) l'impression pénible que cette progression ralentie pourrait bien ne pas aller jusqu'à son terme mais s'enliser vers la fin. Avec la version developper beta 10.13.4 --> j'ai même dans le final de ce dernier tiers (le processus de mise en service de launchd) un saut d'écran avec un écran totalement noir pendant un temps assez important. Tout ce qu'il faut pour donner l'impression que c'est planté.

 

[Le docteur]

Ce qui tu dis semble coller.
Par contre ce qui est étonnant, c'est que la façon dont ça fonctionne chez toi, ressemble à mon scénario 3 (qui colle moins avec l'hypothèse que tu développe ici).
J'ai revérifié en ce qui me concerne, ça donne
- pomme et barre de chargement apparaissent assez rapidement
- le cheval au trot pendant une bonne moitié du chargement
- début de ralentissement puis ralentissement et sorte d'arrêt
- changement de couleur et chargement rapide de la fenêtre de connexion

Le système se lance en mode "serveur" donc ? Ca me fait penser aux serveurs X (graphiques) sur Linux.

 

[Le docteur]

Je pourrais peut-être essayer de repasser en HFS+ au lieu d'APFS
(est-ce que ce dernier a de vrais avantages?)

 

[Le docteur]

Dernières nouvelles étranges.
J'ai essayé de recoller Sierra (entre temps j'ai écopé d'un bug concernant la touche majuscule de droite qui devenait capricieuse). J'ai tout effacé, foiré ma réinstallation (il fallait que je fasse une clé au lieu de lancer l'installateur depuis le clone comme je fais en général, c'était le truc de trop au milieu de déjà plein d'autres).
Du coup j'ai réinjecté le clone depuis CCC.
Je me suis aperçu entre temps que :
— (grâce à un tuto de CCC) l'utilitaire de disque avait des fonctions cachées (pas trop cachées en plus)
— CCC reconstruisait les partitions (virtuelles?) nécessaires pour HS, il n'y avait rien à faire, même pas à refaire sur demande la partition de restauration, tout est automatique.
— mon boot est redevenu normal

MORALITÉ : Bombich devrait être payé par Apple pour le SAV qu'il leur évite.