M
Membre supprimé 1060554
Invité
Ceci est un facétie discursive abusant des effets « yau de poêle »
(dont on sait qu'ils ne sont jamais à court de rallonges)
(dont on sait qu'ils ne sont jamais à court de rallonges)
r e m y
a le chic pour pointer du ☞ ce qui paraît d'entrée de simples points de détails « bizarres », s'avérant à les scruter des sujets de réflexion passionnants (pour un esprit scolastique)
Je me souviens naguère de sa constatation d'une augmentation du délai de boot induite par une augmentation de la quantité de RAM - ce qui donna lieu à la formulation humoristique d'un « paradoxe de r e m y ».
Par ailleurs, dans un fil récent, la mise en épingle du temps de boot incroyablement lent sur le Système de secours de la «Recovery HD» en comparaison du temps de boot sur l'OS principal, alors même qu'un Système de récupération est un OS allégé - ce qui pourrait encore se désigner comme un paradoxe de démarrage.
Enfin, dans ce fil même, l'évocation du cas de figure d'un RAMDisk - le « paradoxe » (si, par souci d'équilibre rhétorique de la distribution des parties du discours, la ré-itération du motif en est ici exigible) étant que le progrès logique d'OS X sur mac OS 9 s'assortirait d'une régression en ce qui concerne la possibilité d'avoir un Système installé dans un RAMDisk, lequel n'aurait plus que des fonctions de stockage éventuelles.
Par ailleurs, dans un fil récent, la mise en épingle du temps de boot incroyablement lent sur le Système de secours de la «Recovery HD» en comparaison du temps de boot sur l'OS principal, alors même qu'un Système de récupération est un OS allégé - ce qui pourrait encore se désigner comme un paradoxe de démarrage.
Enfin, dans ce fil même, l'évocation du cas de figure d'un RAMDisk - le « paradoxe » (si, par souci d'équilibre rhétorique de la distribution des parties du discours, la ré-itération du motif en est ici exigible) étant que le progrès logique d'OS X sur mac OS 9 s'assortirait d'une régression en ce qui concerne la possibilité d'avoir un Système installé dans un RAMDisk, lequel n'aurait plus que des fonctions de stockage éventuelles.
Cet aperçu rétrospectif témoigne d'une « cohérence logique obsessionnelle » dans l'attention au paradoxe (dirait le psychanalyste, s'il en était un qui combinât l'introspection psychologique avec la domaine logique de l'informatique
Et comme rien ne m'enchante plus que de chercher à comprendre ce qu'a priori je n'entrave guère > me voici toujours en train de revenir déranger les porcelaines de ces magasins de curiosités avec ma grâce éléphantine...
--------------------
J'ai donc un peu cogité dans mon bac à sable dominical concernant le procédé de création d'un RAMDisk et voici ce qu'il en est ressorti => la commande bricolée suivante :
Bloc de code:
TAILLE=[nombre de blocs] MONBIDULE=`hdiutil attach -nomount ram://$TAILLE` && diskutil partitionDisk gpt jhfs+ DISK $MONBIDULEPour les correspondances :
Bloc de code:
1 GB = 2097152 blocs
2 GB = 4194304 blocs
3 GB = 6291456 blocs
4 GB = 8388608 blocs
5 GB = 10485760 blocs
6 GB = 12582912 blocs
7 GB = 14680064 blocs
8 GB = 16777216 blocs
9 GB = 18874368 blocs
10 GB = 20971520 blocs=> je m'en tiens là, car il est évident que la RAM étant une denrée d'une quantité toujours limitée, il convient d'en laisser toujours une partie libre suffisante pour le fonctionnement de l'OS lancé. 16 GB étant la quantité disons « confort **** », 6 GB de RAM laissés au Système semble la valeur à ne pas transgresser.
Ce point admis, ma commande bricolée ci-dessus se laisse très bien décomposer en 2 opérations analytiques élémentaires (à partir dequelles je l'ai synthétisée) :
- a) d'abord, une commande simple :
(je prends ici en exemple la valeur en blocs 2097152 équivalant à une taille de 1,1 GB) crée directement dans l'espace de la RAM un container logique émulant un disque dur d'une taille de 1,1 GB.
En effet, une commande informative :
dans la foulée, à supposer qu'il n'y ait d'attaché au Mac que le disque interne identifié comme disk0, retourne un :
où l'on voit clairement que notre container-disque logique n'a ni table de partition, ni format de système de fichiers capable d'exporter un volume montable. Bref : c'est un container nu, un simple périmètre d'image-disque vide inscrit dans l'espace de la RAM.
- b) ensuite, une commande tout aussi élémentaire :
convoque diskutil avec le verbe partitionDisk (mais le verbe eraseDisk aurait aussi fait l'affaire en mode élémentaire) et les paramétrages : écrire une table GPT et créer un volume principal [FORMAT=JHFS+] [NOM=DISK] [TAILLE=100%] > suite à quoi, un volume monté DISK apparaît sur le Bureau d'une taille de 1,1 GB. Une commande diskutil list me retourne un :
ce qui révèle qu'un RAMDisk, càd. un container logique en RAM émulant un disque dur, se laisse entièrement mapper par une table de partition, avec inscription de systèmes de fichiers sur les partitions, à identité avec une image-disque classique de type .dmg ou un disque dur traditionnel. Un RAM-container de plus grande taille (j'ai essayé avec 12 GB) supporte le multi-partitionnement, avec diversité de systèmes de fichiers, de type jhfs+ > exFAT par exemple (je note que la table GPT ne comporte pas par défaut d'ESP - EFI System Partition - de 209 Mo en en-tête dans un container-RAM).
Bloc de code:
hdiutil attach -nomount ram://2097152En effet, une commande informative :
Bloc de code:
diskutil list
Bloc de code:
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: +1.1 GB disk1- b) ensuite, une commande tout aussi élémentaire :
Bloc de code:
diskutil partitionDisk /dev/disk1 gpt jhfs+ DISK 100%
Bloc de code:
/dev/disk1 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +1.1 GB disk1
1: Apple_HFS DISK 1.1 GB disk1s1Et le CoreStorage ? Il est entièrement supporté à destination d'un RAMDisk. Une commande de type :
Bloc de code:
diskutil coreStorage convert /dev/disk1s1
Bloc de code:
diskutil coreStorage encryptLV [LVUUID] -passphrase totoÀ partir de là, il est possible de s'amuser à monter et démonter le volume logique (chiffré - ha ! ha !). Bon : j'arrête ici de me poiler, sous peine d'avoir à me raser prochainement.
--------------------
Un pareil volume monté à partir d'un RAMDisk a-t-il un intérêt ? - oui, théoriquement parlant, car les vitesses d'accès en lecture / écriture y sont environ 9 fois plus rapides que celles à destination du volume d'un SSD (j'ai bien dit : un SSD). Ce qui est impressionnant comme différentiel.
Mais si je voulais utiliser ce volume monté du RAMDisk (volume standard, ou volume logique) pour autre chose que du stockage ? Pas de problème, à part qu'on ne peut pas procéder à une installation régulière (à supposer qu'il n'y ait pas de problème d'espace-disque global du container logique en RAM), parce qu'une installation régulière implique toujours un re-démarrage préalable sur le disque de destination après injection d'un dispositif logique de boot, ce qui n'est pas supporté par un RAMDisk, puisqu'un re-démarrage équivaut à une coupure momentanée de la RAM, ce qui effacerait le RAMDisk.
Par contre, il est trivial d'installer dans un RAMDisk un Système en mode "restore" => ainsi, après une commande :
Bloc de code:
diskutil mount disk0s3
Bloc de code:
sudo asr restore -s /Volumes/Recovery\ HD -t /Volumes/DISK --erase --noprompt--------------------
L'aimable lectorat est en train de se dire que le sieur macomaniac perd le fil (forcément filandreux) de son discours, appendu ab origine aux bizarres paradoxes que r e m y aime tant formuler et qui auraient de surcroît entre eux des relations de consécution logique de type : » yau de poêle ». Eh bien, que nenni !
Car n'ai-je pas introduit dans mon container-RAM un Système, qui est celui même de la «Recovery» ? Ce qui me permet de faire à présent du travail de ravaudage discursif.
Lorsqu'on démarre un Mac selon le mode "par internet" (⌘⌥R), qu'est-ce qui se passe ? Eh bien ! on sait qu'un Système de type Recovery se télécharge en RAM. Comment ? Mais tout devient clair à présent : après connexion du Mac à l'AppStore, une instruction préalable doit nécessairement créer dans l'espace de la RAM du Mac-cible un container logique RAMDisk, avec table de partition GUID et volume exporté au format JHFS+. De quelle taille ? De la taille du Système décompressé du disque virtuel BaseSystem.dmg de la récupération, soit 1,2 Go. Dans ce volume du RAMDisk, il y a copie d'un boot_loader boot.efi, d'un cache de démarrage prelinkedkernel, de fichiers d'instruction de boot et du disque virtuel BaseSystem.dmg. compressé de 450 Mo.
Donc la question est réglée : un RAMDisk peut très bien servir encore de disque de boot pour un Système, puisque la «Récupération par internet» en exploite le procédé. Donc le paradoxe d'OS X rétrograde par rapport à Mac SO 9 sur la question n'est qu'apparent.
Oui, mais l'autre paradoxe de r e m y ne devient-il pas plus critique ? - celui de la lenteur de boot du Système d'une «Recovery», alors qu'ici ce Système se trouve installé dans un RAMDisk censé être fulgurant ?
Attention ! ne pas tout confondre. Je pense que j'ai trouvé en chemin la véritable raison pour laquelle le boot sur le Système régulier de la «Recovery HD» est si lent (Système résidant sur une partition du disque) : c'est que ce Système est initié par le kernel de cette partition à partir du montage en volume du disque virtuel BaseSystem.dmg => or, ce disque est extrêmement compressé, car il ne fait que 450 Mo et qu'il doit décompresser les fichiers de sa partition en un volume de 1,2 Go. C'est ce processus de décompression d'un disque hautement compressé qui doit être la raison de la lenteur du boot sur la «Recovery HD» régulière.
Oui, mais la récupération par internet ? Eh bien ! la seule chose qui prenne du temps, c'est le téléchargement en RAM des 450 Mo du disque BaseSystem.dmg. Car, à peine complété ce téléchargement dans le volume du RAMDisk d'accueil, la décompression du BaseSystem.dmg de 450 Mo en un volume (volume OS X Base System coiffant le volume du RAMDisk) de 1,2 Go et le le lancement de son Système de secours est fulgurante ! Vitesse RAM oblige : c'est quasi instantané ! Rien à voir avec la pénible décompression de la «Recovery HD».
Bon d'accord ! Mais comment ça boote, alors ? C'est cet aspect des paradoxes de r e m y qui m'a le plus tracassé (j'avoue : je suis péniblement gêné dans mes spéculations par mon absence totale de formation informatique. Je n'ai comme adjuvant que mes ressources de logicien formé à la philosophie). Voici ce qui m'apparaît :
Le Mac n'est pas préalablement démarré d'un point de vue software, dans le processus de type «Recovery Internet» : sa RAM est purement un espace-cible manipulé à distance par le Système d'un Serveur de l'AppStore. Après création d'un RAMDisk dans la RAM, avec tous les éléments d'un Système démarrable : boot_loader > prelindekdkernel > Système recelé dans une image-disque montable, le boot_loader boot.efi du RAMDisk doit être directement exécuté à partir du Système distant de l'AppStore (en courcircuitage radical de l'EFI de la Carte-Mère) => la conséquence en est qu'un re-démarrage n'est pas requis pour redonner la main à l'EFI > donc il n'y a pas de coupure de la RAM, mais, la RAM préservée sous tension et donc le RAMDisk maintenu en RAM, le boot.efi charge directement le cache prelinkedkernel en RAM > le kernel y recelé se fait injecter les extensions puis monte le BaseSystem.dmg en un volume OS X Base System adressable et initie le launchd daemon qui prend la main pour activer le Système de la Récupération Internet. Sans délai de décompression (RAM oblige). À peine 1 seconde pour le tout.
[Résolu]
--------------------
Je vois 2 problèmes avec ces RAMDisk :
- c'est que la taille de la RAM des Macs n'a pas augmenté en proportion de la taille des Systèmes à charger et de la taille des disques. Donc la quantité de RAM exploitable pour un RAMDisk reste dérisoire. Qu'est-ce que c'est que 10 GB, voire un peu plus ? Si j'avais un Mac Desktop avec 64 GB de RAM, je pourrais envisager un RAMDisk de 32 GB, voire plus, ce qui reste un peu maigre, par les temps qui courent. À quand des RAM de 128 GB ou de 256 GB ?
- l'autre problème critique est lié au caractère volatile des écritures en RAM. Si j'installais un Système dans un RAMDisk d'une taille suffisante (largement supérieure par hypothèse au Système d'une «Recovery Internet») > comment je me débrouillerais pour le démarrer ? Parce qu'il faut pouvoir exécuter directement le boot_loader sans rendre la main à l'EFI pour ce faire, car repasser par l'EFI implique un re-démarrage, c'est-à-dire une coupure de le RAM qui va effacer le RAMDisk recelant le Système. Mais le problème est que, si je peux restaurer un Système non-démarré dans un RAMDisk, la RAM se trouve occupée en parallèle, dans le reste de son espace, par les éléments du Système démarré depuis lequel j'ai monté mon RAMDisk : kernel_task etc.
Je fais comment pour switcher sans re-démarrer ? Eh bien ! dans le cas de figure que je viens de décrire, ça ne switche pas. Il faudrait que j'adresse la RAM d'un Mac-cible (non-démarré au niveau software) à partir du Système d'un Serveur, après avoir fait se connecter le Mac en mode dépendant.
Quoi qu'il en soit de ces difficultés réelles du boot d'un Système résidant dans un RAMDisk, les vitesses étourdissantes de fonctionnement en RAM laissent penser qu'il y aurait là une perspective alléchante. Curieusement pas tant explorée que cela.- l'autre problème critique est lié au caractère volatile des écritures en RAM. Si j'installais un Système dans un RAMDisk d'une taille suffisante (largement supérieure par hypothèse au Système d'une «Recovery Internet») > comment je me débrouillerais pour le démarrer ? Parce qu'il faut pouvoir exécuter directement le boot_loader sans rendre la main à l'EFI pour ce faire, car repasser par l'EFI implique un re-démarrage, c'est-à-dire une coupure de le RAM qui va effacer le RAMDisk recelant le Système. Mais le problème est que, si je peux restaurer un Système non-démarré dans un RAMDisk, la RAM se trouve occupée en parallèle, dans le reste de son espace, par les éléments du Système démarré depuis lequel j'ai monté mon RAMDisk : kernel_task etc.
Je fais comment pour switcher sans re-démarrer ? Eh bien ! dans le cas de figure que je viens de décrire, ça ne switche pas. Il faudrait que j'adresse la RAM d'un Mac-cible (non-démarré au niveau software) à partir du Système d'un Serveur, après avoir fait se connecter le Mac en mode dépendant.
--------------------
Dernière édition par un modérateur:
