Mac OS X, les PC users ne rigolent pas, au contraire !

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
74 711
22 718
Forêt de Fontainebleau
Ceci est un facétie discursive abusant des effets « yau de poêle »
(dont on sait qu'ils ne sont jamais à court de rallonges)

r e m y
:coucou: 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.​

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
) : à savoir les relations triangulaires entre les facteurs RAM > BOOT > SYSTÈME.

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 $MONBIDULE
génère directement un volume monté intitulé DISK, de la taille correspondante au nombre de blocs mentionnés en tête comme valeur de la variable TAILLE, exporté par un container émulant un disque dur dans l'espace de la RAM.

Pour 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 :
Bloc de code:
hdiutil attach -nomount ram://2097152
(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 :
Bloc de code:
diskutil list
dans la foulée, à supposer qu'il n'y ait d'attaché au Mac que le disque interne identifié comme disk0, retourne un :
Bloc de code:
/dev/disk1 (disk image):
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:                                                   +1.1 GB     disk1
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 :
Bloc de code:
diskutil partitionDisk /dev/disk1 gpt jhfs+ DISK 100%
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 :
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     disk1s1
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).​

Et le CoreStorage ? Il est entièrement supporté à destination d'un RAMDisk. Une commande de type :
Bloc de code:
diskutil coreStorage convert /dev/disk1s1
génère sans aucun problème un format CoreStorage sur la partition disk1s1 du container-RAM. Et un format Chiffré ? Aucun problème : il suffit de passer la commande :
Bloc de code:
diskutil coreStorage encryptLV [LVUUID] -passphrase toto
pour que le Volume Physique du RAM-Container soit chiffré au niveau de ses blocs, avec requête d'un mot-de-passe toto pour activer la clé de déchiffrement et monter le Volume Logique DISK (la vitesse exécutive du processus de chiffrement est phénoménale).

À 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
qui monte le système de fichiers de la partition de récupération «Recovery HD» comme : /Volumes/Recovery\ HD > il suffit d'enchaîner par la commande :
Bloc de code:
sudo asr restore -s /Volumes/Recovery\ HD -t /Volumes/DISK --erase --noprompt
et une recopie conforme - théoriquement bootable - du Système de la récupération dans le volume DISK exporté par le container RAMDisk s'effectue. À une vitesse é-tour-dis-san-te ! Il ne faut même pas 2 secondes au processus asr pour copier bloc à bloc puis vérifier bloc à bloc ( de 10% à 100% chaque fois) les 1,2 Go du volume de la Recovery HD dans le volume monté DISK.

--------------------​

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.

--------------------​
 
Dernière édition:

melaure

Chasseur de Bobos
Club MacG
24 Octobre 2001
24 810
1 725
50
Le Grand Lyon
Je me rappelle une fonctionnalité qui n'est plus imaginable aujourd'hui: le RAMDisk qui permettait d'affecter une partie de la RAM à un disque virtuel sur lequel on pouvait copier un dossier systeme et rebooter dessus (donnant un réactivité incroyable!)
Oui je l'avais largement utilisé dans les années 97/98. Ca donnait un bon coup de boost, car les SSD n'existait pas. Bompi, on ne parle pas d'aujourd'hui, mais d'il y a 20 ans. Et ces quelques fonctionnalités de l'OS Classic étaient excellentes pour leur époque.
 

r e m y

Cas clinique
Club MacG
4 Novembre 2000
41 492
4 300
58
St Germain en Laye - FRANCE
Exactement....c'est egalement en me re projetant 20 ans en arrière que j'évoquais cette fonctionnalité de MacOS d'un systeme bootable en RAMDisk (qui prenait quelques secondes à créer et quelques secondes de plus pour redémarrer dessus). Juste pour montrer que tout n'était pas à jeter sur cet ancêtre!

Il faut dire qu'il n'était pas rare de devoir réparer la structure du disque dur en démarrant sur un autre disque. Lancer les Norton Utilities etait nettement plus rapide depuis un Ramdisque que depuis un disquette!
 

bompi

El Moderador
Modérateur
Club MacG
12 Février 2004
41 926
3 160
Oui je l'avais largement utilisé dans les années 97/98. Ca donnait un bon coup de boost, car les SSD n'existait pas. Bompi, on ne parle pas d'aujourd'hui, mais d'il y a 20 ans. Et ces quelques fonctionnalités de l'OS Classic étaient excellentes pour leur époque.
J'ai bien compris et c'est bien ce dont je parlais : il y a 20 ans, et même davantage, j'utilisais aussi des RAM disks sur les divers UNIX que j'utilisais (Linux, *BSD, SunOS 4 puis Solaris pour l'essentiel).
Sans avoir la possibilité de démarrer directement sur une partition système sur ce RAM disk : je ne sais pas si c'était possible, en tout cas je ne l'ai jamais tenté.

J'ai ensuite simplement précisé que c'est toujours possible de le faire, même sous OS X. Comme quoi certaines techniques ont la vie dure.
 

melaure

Chasseur de Bobos
Club MacG
24 Octobre 2001
24 810
1 725
50
Le Grand Lyon
Certes ... il y a 20 ans, j'avais aussi de l'Unix au boulot (d'ailleurs je commençais mon premier boulot pour HP en 96, site de prod, et je bossais sous HP/UX), après en avoir bien profité pendant mes études, mais pas chez moi. Le coût d'une station était bien plus cher qu'un Mac ... et je ne me voyais pas bien avec un serveur HP série G ou I de la taille d'un frigo dans mon salon ... ;) :D :p

Je n'ai pas essayé sous OS X, mais avec l'avènement des SSD de plus en plus rapide, l'intérêt diminue fortement ... Actuellement je bosse surtout sur AIX (matos Bull + IBM), on n'utilise plus de RAM disque vu les perfs de nos baies IBM. Et le jour ou on passera sur baies de SSD, genre Bull Storeway/EMC EXtrem/IO ..., ça va faire encore plus mal :D