IPB

Bienvenue invité ( Connexion | Inscription )

 
Reply to this topicStart new topic
> La norme NVMe passe en version 1.4, Réactions à la publication du 15/06/2019
Options
Lionel
posté 15 Jun 2019, 06:53
Message #1


BIDOUILLE Guru
*****

Groupe : Admin
Messages : 53 487
Inscrit : 14 Jan 2001
Lieu : Paris
Membre no 3



Arrivée en 2011, la norme NVM express a permis aux SSD de gagner en performances grâce à l'abandon du protocole SATA III qui n'était pas adapté aux systèmes de stockage utilisant de la mémoire Flash.

Cette norme vient de passer en version 1.4 et inclut des améliorations destinées à améliorer encore les performances des supports basés sur de la mémoire Flash.
La première amélioration est liée à une optimisation devenue indispensable à cause des puces de Flash modernes. Ces dernières n'utilisent plus des blocs de 512 octets, mais de 4 Ko ou plus. Cela signifie que toute modification du moindre octet oblige à réécrire un bloc d'une taille très supérieure ce qui prend du temps et use les cellules. La norme 1.4 permet au SSD de communiquer plus efficacement avec le système d'exploitation pour gérer au mieux ces blocs en fonction de leur taille. On y gagne en performances et en endurance.
La seconde concerne la gestion de la mémoire vive présente sur tous les SSD. Elle sera mieux gérée pour d'un côté accélérer les accès mais aussi gérer un cache local des tables d'allocation des données.
De grosses améliorations ont été aussi apportées sur les files d'attente de commandes à exécuter. Pour commencer, chaque cœur des contrôleurs SSD pourra en avoir une indépendante et ils n'auront donc plus à devoir communiquer entre eux pour gérer les écritures, de quoi libérer la puissance.
Il sera aussi possible de créer plusieurs files d'attentes, certaines prioritaires par rapport à d'autres. Il sera également possible de gérer des écritures ultraprioritaires qui mettront toutes les autres en pause pour obtenir les meilleurs débits et une latence minimale quand c'est nécessaire.
On peut ajouter à cela un nouveau mode de protection de certaines données qui seront verrouillées et impossibles à effacer.

D'autres fonctions sont encore ajoutées mais elles concernent surtout les SSD destinés aux centres de données avec l'amélioration de la gestion de grappes de disques en RAID et des systèmes de correction d'erreurs plus avancés.

Il ne reste plus qu'à espérer qu'Apple implémente rapidement cette nouvelle norme dans ses contrôleurs Tx.

Lien vers le billet original



--------------------
C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
Go to the top of the page
 
+Quote Post
fudo
posté 15 Jun 2019, 08:18
Message #2


Macbidouilleur d'argent !
***

Groupe : Membres
Messages : 570
Inscrit : 1 Oct 2004
Membre no 24 498



Cette norme sera-t-elle matérielle ou une màJ carte mère / SSD suffira t-elle pour en bénéficier ?


--------------------
Hackintosh 1 (config thin ITX fanless) : Akasa Euler / Asus Q87T / i5 4590T / SSD Samsung Pro 128 Go / Atheros 9280 a/b/g/n, Mavericks via Multibeast
Hackintosh 2 (en cours) : Streacom DB4 / Corsair SF600 / Asus Z370-i / i7-8700T / WiFi & BT carte Apple + adaptateur M.2-PCIe / MSI RX560 / SSD 512Go M.2 NVMe x2 (multiboot)
Go to the top of the page
 
+Quote Post
ekami
posté 15 Jun 2019, 11:05
Message #3


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 5 084
Inscrit : 9 Apr 2004
Membre no 17 402



Citation (fudo @ 15 Jun 2019, 09:18) *
Cette norme sera-t-elle matérielle ou une màJ carte mère / SSD suffira t-elle pour en bénéficier ?

Il faudrait le demander aux concepteurs…
nvmexpress.org


--------------------
Go to the top of the page
 
+Quote Post
chammer
posté 15 Jun 2019, 11:53
Message #4


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 340
Inscrit : 16 May 2002
Membre no 2 488



Citation (Lionel @ 15 Jun 2019, 06:53) *
Il ne reste plus qu'à espérer qu'Apple implémente rapidement cette nouvelle norme dans ses contrôleurs Tx.

Lien vers le billet original


On a déjà mieux que cela avec T2 et l'APFS.

APFS a accès à l'ensemble des informations du support, y compris les tâches de maintenance et les ECC matériels.
En plus simple et plus sûr, car il n'y a pas de contrôleur du fabricant, un firmware (et ses mises à jour), une FTL et un FS tiers.

Mais pas de bidouille sur cela, comme à l'époque des firmware Apple de disques durs.
Rappelez-vous, il y avait une pomme sur dessus wink.gif

NVMe 1.4 sera utile pour les MacPro 2019 PCIe Gen4 (en tout cas j'espère) : le débit potentiel sera de 30 Go/s.
Le prix sera sans doute élitiste lui aussi.

Tant qu'apple ne se décide pas à faire un Macmini "pro" (écrivez le à Apple !), la bidouille restera externe.
Au moins les connecteurs sont standards, contrairement aux premiers Mac.


--------------------
"Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule.
Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) "
-+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Go to the top of the page
 
+Quote Post
vlady
posté 15 Jun 2019, 14:06
Message #5


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 875
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (chammer @ 15 Jun 2019, 11:53) *
Citation (Lionel @ 15 Jun 2019, 06:53) *
Il ne reste plus qu'à espérer qu'Apple implémente rapidement cette nouvelle norme dans ses contrôleurs Tx.

Lien vers le billet original


On a déjà mieux que cela avec T2 et l'APFS.

APFS a accès à l'ensemble des informations du support, y compris les tâches de maintenance et les ECC matériels.
En plus simple et plus sûr, car il n'y a pas de contrôleur du fabricant, un firmware (et ses mises à jour), une FTL et un FS tiers.

Mais pas de bidouille sur cela, comme à l'époque des firmware Apple de disques durs.
Rappelez-vous, il y avait une pomme sur dessus wink.gif

NVMe 1.4 sera utile pour les MacPro 2019 PCIe Gen4 (en tout cas j'espère) : le débit potentiel sera de 30 Go/s.
Le prix sera sans doute élitiste lui aussi.

Tant qu'apple ne se décide pas à faire un Macmini "pro" (écrivez le à Apple !), la bidouille restera externe.
Au moins les connecteurs sont standards, contrairement aux premiers Mac.


Sauf que les débits ne sont pas franchement supérieurs. Et la stabilité de bridgeOS (dérivé du watchOS), une mini usine à gaz qui "fait la mayonnaise", ne vaut pas la stabilité des contrôleurs largement utilisés dans l'industrie. Et bien sûr, bridgeOS n'a pas besoin être mise à jour... rotfl.gif
(et je ne parle pas d'avantages d'avoir des pièces standards)

Une autre info, même avec T2 (et surtout avec T2), le SSD est vu par macOS comme un SSD NMVe. C'est justement grâce à ça la bidouille d'adaptateur NVMe est possible sur des "veux" mac et sur un trash can notamment (comme le mien).

Ce message a été modifié par vlady - 15 Jun 2019, 14:28.


--------------------
Mac Pro late 2013 Xeon Quad 3.7GHz/16GB, écran Eizo EV2736W, Mac Book Air 11" 1.6GHz/4GB, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
SartMatt
posté 15 Jun 2019, 14:18
Message #6


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (chammer @ 15 Jun 2019, 12:53) *
NVMe 1.4 sera utile pour les MacPro 2019 PCIe Gen4 (en tout cas j'espère) : le débit potentiel sera de 30 Go/s.
N'espère pas, ce sera du PCIe Gen3.


--------------------

Go to the top of the page
 
+Quote Post
vlady
posté 15 Jun 2019, 14:37
Message #7


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 875
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (SartMatt @ 15 Jun 2019, 14:18) *
Citation (chammer @ 15 Jun 2019, 12:53) *
NVMe 1.4 sera utile pour les MacPro 2019 PCIe Gen4 (en tout cas j'espère) : le débit potentiel sera de 30 Go/s.
N'espère pas, ce sera du PCIe Gen3.


Et visiblement le SSD du mac pro 2019 n'est pas si rapide que ça.

https://www.macg.co/mac/2019/06/le-mac-pro-...la-gamme-106474


--------------------
Mac Pro late 2013 Xeon Quad 3.7GHz/16GB, écran Eizo EV2736W, Mac Book Air 11" 1.6GHz/4GB, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
zero
posté 15 Jun 2019, 15:06
Message #8


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 11 707
Inscrit : 25 Nov 2001
Membre no 1 397



Citation (Lionel @ 15 Jun 2019, 14:53) *
Cette norme vient de passer en version 1.4 et inclut des améliorations destinées à améliorer encore les performances des supports basés sur de la mémoire Flash.
La première amélioration est liée à une optimisation devenue indispensable à cause des puces de Flash modernes. Ces dernières n'utilisent plus des blocs de 512 octets, mais de 4 Ko ou plus. Cela signifie que toute modification du moindre octet oblige à réécrire un bloc d'une taille très supérieure ce qui prend du temps et use les cellules.

La taille des clusters et secteurs dépendent de la taille du disque/partition et du formatage. Je ne vois pas le rapport entre ça et une interface. Plus les clusters ou secteurs sont grands, plus les blocs à écrire dans la mémoire flash sont grand donc, c'est plus lent et elle s'use plus vite. Quelque soit le type d'interface, ça ne devrait rien changer sur ce point. A la limite, seul le controlleur du SSD peut améliorer la chose.

Ce message a été modifié par zero - 15 Jun 2019, 15:07.
Go to the top of the page
 
+Quote Post
iAPX
posté 15 Jun 2019, 15:40
Message #9


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 11 995
Inscrit : 4 Jan 2006
Lieu : Montréal
Membre no 52 877



Citation (zero @ 15 Jun 2019, 10:06) *
Citation (Lionel @ 15 Jun 2019, 14:53) *
Cette norme vient de passer en version 1.4 et inclut des améliorations destinées à améliorer encore les performances des supports basés sur de la mémoire Flash.
La première amélioration est liée à une optimisation devenue indispensable à cause des puces de Flash modernes. Ces dernières n'utilisent plus des blocs de 512 octets, mais de 4 Ko ou plus. Cela signifie que toute modification du moindre octet oblige à réécrire un bloc d'une taille très supérieure ce qui prend du temps et use les cellules.

La taille des clusters et secteurs dépendent de la taille du disque/partition et du formatage. Je ne vois pas le rapport entre ça et une interface. Plus les clusters ou secteurs sont grands, plus les blocs à écrire dans la mémoire flash sont grand donc, c'est plus lent et elle s'use plus vite. Quelque soit le type d'interface, ça ne devrait rien changer sur ce point. A la limite, seul le controlleur du SSD peut améliorer la chose.

Ouhhhlllaaaaa on a quitté le FAT12 depuis un moment si je puis me permettre.

En APFS les choses sont extrêmement différente, puisqu'un filesystem orienté journal conçu pour les supports à stockage Flash.
Les "secteurs" (de 4K couramment aujourd'hui) sont malheureusement un reliquat d'un passé très lointain qui n'a aucun sens pour de la mémoire Flash, et qu'il serait bon de mettre au rebut un jour!
Quand à notion de formatage, elle n'a pas le même sens avec la mémoire Flash (désallocation et éventuellement effacement) qu'avec les premiers supports magnétiques pour lesquels cette opération "formatait" le média en y inscrivant les informations nécessaire pour repérer les blocks voir les pistes.

Le secteur de 4Ko est une convention, servant à émuler le fonctionnement de périphériques anciens (dont certains obsolètes) et avec un fs orienté Journal (donc orienté séquentiel au moins virtuellement en écriture), l'influence de blocs plus grands permet d'écrire plus rapidement grâce à la diminution du nombre d'allocations et de limitation du mapping d'adressage.
Les progrès viendront quand le stockage Flash sera géré avec un protocole adapté et non une émulation de bande-magnétique ou de tambour magnétique!

Ce message a été modifié par iAPX - 15 Jun 2019, 15:41.


--------------------
Un Mac, un iPhone, un iPod, la première montre bracelet.
Go to the top of the page
 
+Quote Post
SartMatt
posté 15 Jun 2019, 16:36
Message #10


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (zero @ 15 Jun 2019, 16:06) *
La taille des clusters et secteurs dépendent de la taille du disque/partition et du formatage. Je ne vois pas le rapport entre ça et une interface.
La taille des clusters dépend du formattage, oui. La taille des secteurs par contre, non, c'est à la fois une contrainte "physique" du support et une contrainte "logique" de son interface. Ça n'a strictement rien à voir avec le formatage et le système de fichier, c'est totalement figé pour un support donné et une interface donnée.

Au niveau des supports, le secteur est la plus petite unité d'allocation que sait gérer le contrôleur. Quelque soit la quantité de données que tu veux lire ou écrire, en pratique, physiquement, ce sera toujours au minimum un secteur physique qui sera lu ou écrit. Ça ne dépend pas de la taille du disque, et encore moins de la partition ou du formatage.

Sur les SSD, il y a même deux types d'unités d'allocation : les pages, qui sont les plus petites unités d'allocation pour les opérations de lecture et d'écriture (programmation), équivalentes donc aux secteurs sur les disques durs, les blocs qui sont les plus petites unités d'effacement (rappel : une mémoire flash ne se réécrit pas, il faut l'effacer d'abord puis la programmer). C'est de ça que Lionel parle dans l'article, et non des clusters du système de fichier.

Au niveau de l'interface, le secteur est la plus petite unité que l'hôte peut adresser. L'adresse 0 correspond à un secteur, l'adresse 1 au secteur suivant, etc... Tu ne peux pas adresser de manière plus précise.

Pendant très longtemps, jusqu'à l'arrivée des SSD, les secteurs faisaient 512 octets aussi bien au niveau des support qu'au niveau des interfaces. Avec l'arrivée des SSD, on a rapidement eu des pages de plus de 512 octets, tandis que les interfaces sont restées à 512 octets. C'est à cause de ça qu'il y a eu les fameux problèmes de performances liées au mauvais alignement des partitions, à l'époque où Windows faisait commencer la première partition au secteur 3 : si le SSD était formaté avec des clusters de plus de 512 octets, certains clusters se retrouvaient à cheval sur deux pages, ce qui provoquait des ralentissement en augmentant la charge du SSD pour les petites opérations de lecture/écriture.

Depuis, les disques durs sont également passés à des secteurs plus gros, de 4 Ko, donc même avec les disques durs, il est désormais important d'aligner correctement les partitions (Windows est par exemple passé à un alignement des partitions au Mo, ce qui permet de couvrir toutes les tailles de secteurs dont 1 Mo est un multiple).

Mais les interfaces sont par contre restées jusqu'à présent sur des secteurs de 512 octets.


--------------------

Go to the top of the page
 
+Quote Post
iAPX
posté 15 Jun 2019, 23:40
Message #11


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 11 995
Inscrit : 4 Jan 2006
Lieu : Montréal
Membre no 52 877



Intéressant, je n'avais pas vu le mélange entre un formatage (avec les différents sens historiques du mot) et la création d'un système de fichier, caché sous le même nom: "formatage" est une bête complexe!

Formatage: effacement complet d'un média (ou des informations qui y sont stockées), désallocation de cartographie du média, enregistrement des informations de localisation physique des informations, création des structures nécessaires à un gestionnaire de fichier, etc.

Je n'aime pas ce mot, il veut dire tellement de choses différentes qui n'ont rien à voir entre elles...


--------------------
Un Mac, un iPhone, un iPod, la première montre bracelet.
Go to the top of the page
 
+Quote Post
zero
posté 16 Jun 2019, 00:23
Message #12


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 11 707
Inscrit : 25 Nov 2001
Membre no 1 397



Citation (SartMatt @ 16 Jun 2019, 00:36) *
La taille des clusters dépend du formattage, oui. La taille des secteurs par contre, non

https://fr.wikipedia.org/wiki/Secteur_de_disque
http://www.materiel-informatique.be/secteur.php

512Ko ~ 4048ko ! (et je peux te donner une floppée de liens vers des exemples si tu veux. J'ai juste pas le temps là.)


Citation (SartMatt @ 16 Jun 2019, 00:36) *
c'est à la fois une contrainte "physique" du support et une contrainte "logique" de son interface. Ça n'a strictement rien à voir avec le formatage et le système de fichier, c'est totalement figé pour un support donné et une interface donnée.

Non, ça dépend du formatage (qui est plus ou moins adapté aux contraintes physiques).


Citation (SartMatt @ 16 Jun 2019, 00:36) *
Au niveau des supports, le secteur est la plus petite unité d'allocation que sait gérer le contrôleur.

Et c'est pour ça que je me demande quel est le rapport avec l'interface (quelle soit SCSI, IDE, SD, SATA ou MVMe).

Citation (SartMatt @ 16 Jun 2019, 00:36) *
Sur les SSD, il y a même deux types d'unités d'allocation

Oui, et c'est au controlleur du disque de gérer ça. C'est pour ça que je me demande ce que vient faire l'intercace dans la News.

Ce message a été modifié par zero - 16 Jun 2019, 00:40.
Go to the top of the page
 
+Quote Post
SartMatt
posté 16 Jun 2019, 08:52
Message #13


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (zero @ 16 Jun 2019, 01:23) *
Citation (SartMatt @ 16 Jun 2019, 00:36) *
La taille des clusters dépend du formattage, oui. La taille des secteurs par contre, non

https://fr.wikipedia.org/wiki/Secteur_de_disque
http://www.materiel-informatique.be/secteur.php

512Ko ~ 4048ko ! (et je peux te donner une floppée de liens vers des exemples si tu veux. J'ai juste pas le temps là.)
Ces liens ne disent pas que la taille des secteurs dépend du formatage ou du partitionnement, bien au contraire, puisque le premier dit même que certains modes de formatage regroupent les secteurs (si les secteurs dépendait du formatage, le formatage n'aurait aucune raison de les regrouper !) et que d'autres se basent sur les secteurs (si les secteurs dépendaient du formatage, on ne pourrait pas baser le formatage dessus !), tandis que le second dit bien que la taille des secteurs est fixe pour un support donné (alors que le partitionnement et le formatage ne le sont pas, preuve que la taille du secteur ne dépend pas de ces variables).

La taille des secteurs et figée au niveau du support. Si ton disque dur à des secteurs de 512 octets, tu peux pas le reformater pour passer à des secteurs de 4 Ko ! À la limite, un changement de firmware du disque pourrait éventuellement changer ça. Mais j'ai jamais vu faire, et dans la plupart des cas je doute fort que ça soit possible, parce qu'il y a sans doute des contraintes physiques qui vont l'empêcher, puisque par exemple dans l'électronique de contrôle du disque, voire dans les têtes, il y a des bufers, dont la taille est sans doute lié à celle des secteurs, les fabricants vont pas mettre des bufers de 10 Ko quand les secteurs ne font que 512 octets.

Citation (zero @ 16 Jun 2019, 01:23) *
Citation (SartMatt @ 16 Jun 2019, 00:36) *
c'est à la fois une contrainte "physique" du support et une contrainte "logique" de son interface. Ça n'a strictement rien à voir avec le formatage et le système de fichier, c'est totalement figé pour un support donné et une interface donnée.
Non, ça dépend du formatage (qui est plus ou moins adapté aux contraintes physiques).
Non, ça ne dépend pas du formatage. Si ça dépendait du formatage, on pourrait modifier ces valeurs en reformatant le disque. Ce n'est pas le cas.

Ce qui dépend du formatage, c'est la taille des clusters, qui sont l'unité d'allocation de base du système de fichier. Pas la taille des secteurs.

Ce point est d'ailleurs bien expliqué dans le second paragraphe du premier lien que tu donnes (ce serait bien de les lire avant de les donner puis d'écrire quelque chose de contradictoire par rapport à tes propres liens...) : "La plupart des systèmes d'exploitation regroupent les secteurs dans leur système de fichiers en unités logiques de stockage appelées bloc sous DOS et unité d'allocation sous Windows. Le nombre de secteurs par bloc varie en fonction de la taille de la partition ou du médium, de 2 pour une disquette (FAT12) à 128 (64 ko) pour les plus grandes partitions ext4, NTFS. "

Et ton second lien aussi, il dit la même chose : le secteur n'est pas liée au formatage ("La taille du secteur est fixe, 512 octets pour la majorité des disques durs, supérieure pour quelques nouveaux modèles."), c'est celle du cluster qui est liée au formatage ("Le formatage logique crée des clusters dont la taille varie en fonction du type d'encodage des partitions et de la taille du disque. Un clusters reprend donc plusieurs secteurs.").

Bref, les liens que tu donnes pour étayer tes propos te contredisent...

Citation (zero @ 16 Jun 2019, 01:23) *
Citation (SartMatt @ 16 Jun 2019, 00:36) *
Au niveau des supports, le secteur est la plus petite unité d'allocation que sait gérer le contrôleur.
Et c'est pour ça que je me demande quel est le rapport avec l'interface (quelle soit SCSI, IDE, SD, SATA ou MVMe).
Tu lis le paragraphe suivant du message, et tu verras le rapport : l'interface aussi a une unité d'allocation de base, et pendant très très très longtemps interface et disques ont utilisé la même taille d'unité d'allocation.

Citation (zero @ 16 Jun 2019, 01:23) *
Citation (SartMatt @ 16 Jun 2019, 00:36) *
Sur les SSD, il y a même deux types d'unités d'allocation
Oui, et c'est au controlleur du disque de gérer ça. C'est pour ça que je me demande ce que vient faire l'intercace dans la News.
Comme je l'ai donné en exemple, quand l'OS n'a pas la connaissance de la taille des unités d'allocation physiques (actuellement, il connait uniquement la taille des unités d'allocation de l'interface, interface qui depuis quelques années n'a plus forcément les mêmes tailles d'unités d'allocation que le support), il peut par exemple mal aligner ses propres unités d'allocation (les clusters du système de fichier, qui, eux, dépendent bien du partitionnement et du formatage), avec en conséquence des problèmes de performance.

D'où l'intérêt que, via l'interface, l'OS puisse interroger le support sur la taille de ses unités d'allocation. Ça peut aussi permettre à l'OS de bufferiser certaines requêtes pour optimiser les accès. Par exemple, si un SSD a des pages de 8 Ko et qu'il fait le mapping des adresses logiques sur les pages (ie que chaque page correspond toujours à n adresses logiques consécutives), il peut être intéressant au niveau de l'OS de bufferiser un peu les écritures (pas trop non plus, puisque ce qui est bufferisé est perdu en cas d'arrêt soudain...), au cas où une écriture sur un des 15 autres secteurs de la même page arriverait dans la foulée. Ça améliorerait les performances, et ça réduirait l'usure. À l'inverse, si le SSD a un mapping totalement libre, il vaut mieux ne rien bufferiser et tout envoyer directement au SSD pour laisser son contrôleur optimiser au mieux.

Il y a également le fait qu'aujourd'hui, comme la plupart des interfaces n'exposent à l'OS que des secteurs physiques de 512 octets, même si en réalité ils sont plus gros, l'OS va découper en plusieurs requêtes les accès à un même secteur physique. Une interface qui exposerait directement les secteurs physiques permettrait de limiter les requêtes et l'overhead qui va avec.


--------------------

Go to the top of the page
 
+Quote Post
marc_os
posté 16 Jun 2019, 12:27
Message #14


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 376
Inscrit : 21 Apr 2006
Membre no 59 799



Les références générales et à Windows c'est bien, et si on parlait Apple ?

Même si l'HFS+ appartient maintenant au passé, les concepts restent.
Citation
The storage space on a disk is divided into units called sectors.
A sector is the smallest part of a disk that the disk's driver software will read or write in a single operation (without having to read or write additional data before or after the requested data).
The size of a sector is usually based on the way the data is physically laid out on the disk. For hard disks, sectors are typically 512 bytes. For optical media, sectors are typically 2048 bytes.

HFS Plus allocates space in units called allocation blocks; an allocation block is simply a group of consecutive bytes. The size (in bytes) of an allocation block is a power of two, greater than or equal to 512, which is set when the volume is initialized.

To promote file contiguity and avoid fragmentation, disk space is typically allocated to files in groups of allocation blocks, or clumps. The clump size is always a multiple of the allocation block size. The default clump size is specified in the volume header.

On peut en gros dire en terme de vocabulaire que :

secteur = sector
unité d'allocation sous Windows = allocation block


La doc d'Apple confirme ce que dit Sartmatt.

Quant aux clumps d'HFS+, pas le temps de chercher le correspondant dans vos échanges (on m'attend).


La documenation d'APFS ne contient pas d'introduction aussi lisible, mais on peut quand même en déduire un certain nombre de choses:

CODE

typedef int64_tpaddr_t;
// Negative numbers arenʼt valid addresses.
// This value is modeled as a signed integer to match IOKit.

struct prange
{
paddr_t pr_start_paddr;
uint64_t pr_block_count;
};


Ça veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets. Donc je dirais qu'APFS semble bien taillé pour exploiter au mieux les SSD.

Quant à l'impact de l'évolution de la norme NVMe sur APFS et ses drivers, à voir, je ne peux rien dire à priori sans étudier plus la chose.

Le reste de la documentation est plus cabalistique et si je reste là maintenant devant l'ordi à l'analyser, on va m'attendre pour déjeuner ! ;-)
Mais si le cœur vous en dit, ne vous gênez pas à l'étudier !

Ce message a été modifié par marc_os - 16 Jun 2019, 12:34.


--------------------
-----------------
--JE-------SUIS--
--AHMED-CHARLIE--
--CLARISSA-YOAV--
-----------------
Go to the top of the page
 
+Quote Post
SartMatt
posté 16 Jun 2019, 13:47
Message #15


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (marc_os @ 16 Jun 2019, 13:27) *
La documenation d'APFS ne contient pas d'introduction aussi lisible, mais on peut quand même en déduire un certain nombre de choses:

CODE

typedef int64_tpaddr_t;
// Negative numbers arenʼt valid addresses.
// This value is modeled as a signed integer to match IOKit.

struct prange
{
paddr_t pr_start_paddr;
uint64_t pr_block_count;
};
Ça veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets. Donc je dirais qu'APFS semble bien taillé pour exploiter au mieux les SSD.
Pour moi ça veut plutôt dire que APFS gère l'adressage sur 64 bits.
Je ne voit rien dans ce que tu donnes qui fasse référence à la taille des secteurs (= blocs physiques). Uniquement la taille des adresses et le nombre de blocs (et on ne sait pas s'il s'agit des blocs physiques ou des blocs logiques du système de fichiers, ces derniers ayant à priori par défaut une taille de 4 Ko en APFS).
La structure prange décrit un ensemble de blocs consécutifs (secteurs ou unités d'allocation), avec une adresse de départ sur 64 bits et un nombre de blocs sur 64 bits.

Gérer des blocs physiques de 8 octets au niveau d'un système de fichier moderne destiné à du stockage de masse, ça n'aurait pas franchement de sens, dans la mesure où :
* aucun support de masse d'aujourd'hui n'a des blocs aussi petits,
* historiquement, sur les 3-4 dernières décennies, il n'y a quasiment aucun support de masse dont les blocs physiques font moins de 512 octets,
* la tendance moderne est à l'accroissement de la taille des blocs physiques, pas à leur diminution (sur les disques durs, on est passé à 4 Ko, sur les SSD on avait des pages de l'ordre de 1 Ko au début, aujourd'hui il n'est pas rare de voir du 16 ou du 32 Ko),
* sur un stockage de masse, on a rarement à manipuler des données aussi petites, donc un support offrant des blocs physiques aussi petits n'apporterait des gains de performances que dans quelques cas ultra-marginaux, et des pertes dans l'écrasante majorité des autres cas : pour une même taille de données, plus les blocs physiques sont petits, plus l'overhead est grand, tant au niveau de l'espace de stockage (pour chaque bloc, il y a un en-tête et un code de correction... sur les disques durs, le passage de secteurs de 512 octet à des secteurs de 4 Ko a permis des gains de capacité de l'ordre de 10% à densité égale, en passant de 65 octets d'en-tête/correction par 512 octets de données à 115 octets par 4 Ko de données) que lors des accès.

Même sur la RAM, on n'accède aujourd'hui quasiment plus jamais à des blocs physiques de seulement 64 bits (même si on adresse des blocs de 8 bits...) : les RAM DDR actuelles sont effectivement 64 bits, mais dans les faits on les utilise quasiment toujours sur deux canaux parallèle ou plus, ce qui fait une taille de bloc minimale de 128 bits.

Peut-être que l'arrivée des RAM non volatiles (PRAM, MRAM et cie) nous amènera à une réduction de la taille des blocs physiques sur les stockage de masse. Mais on est sans doute encore loin de l’avènement de ces types de stockage, et quand ils seront utilisés pour du stockage de masse je ne serai pas surpris que les fabricants optent tout de même pour des secteurs assez "gros", pour améliorer la capacité utile.

Ce message a été modifié par SartMatt - 16 Jun 2019, 14:08.


--------------------

Go to the top of the page
 
+Quote Post
zero
posté 16 Jun 2019, 14:25
Message #16


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 11 707
Inscrit : 25 Nov 2001
Membre no 1 397



Ok, la taille secteur peut varrier seulement en fonction du type de disque mais cela ce change rien à ce que je veux dire.
Go to the top of the page
 
+Quote Post
marc_os
posté 16 Jun 2019, 15:20
Message #17


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 376
Inscrit : 21 Apr 2006
Membre no 59 799



Citation (SartMatt @ 16 Jun 2019, 13:47) *
Citation (marc_os @ 16 Jun 2019, 13:27) *
La documenation d'APFS ne contient pas d'introduction aussi lisible, mais on peut quand même en déduire un certain nombre de choses:

CODE

typedef int64_tpaddr_t;
// Negative numbers arenʼt valid addresses.
// This value is modeled as a signed integer to match IOKit.

struct prange
{
paddr_t pr_start_paddr;
uint64_t pr_block_count;
};
Ça veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets. Donc je dirais qu'APFS semble bien taillé pour exploiter au mieux les SSD.
Pour moi ça veut plutôt dire que APFS gère l'adressage sur 64 bits.
[...]
La structure prange décrit un ensemble de blocs consécutifs (secteurs ou unités d'allocation), avec une adresse de départ sur 64 bits et un nombre de blocs sur 64 bits.

Ai-je dit autre chose ?
Contredire pour contredire, encore et encore.
Si ça t'amuse...

Et bien entendu en, en toute cohérence en me citant tu as viré tu as viré cette phrase :
Quant à l'impact de l'évolution de la norme NVMe sur APFS et ses drivers, à voir, je ne peux rien dire à priori sans étudier plus la chose.

Citation (SartMatt @ 16 Jun 2019, 13:47) *
Je ne voit rien dans ce que tu donnes qui fasse référence à la taille des secteurs (= blocs physiques). Uniquement la taille des adresses et le nombre de blocs (et on ne sait pas s'il s'agit des blocs physiques ou des blocs logiques du système de fichiers, ces derniers ayant à priori par défaut une taille de 4 Ko en APFS).

Analyser le reste de la documentation d'Apple ça non.
Mais émettre des à priori, de ton propre aveu, ça oui.
Bref comme d'hab, l'essentiel pour toi n'est pas l'objectivité et encore moins la rigueur scientifique. confused5.gif
Aller, je te laisse avec tes certitudes.

Ce message a été modifié par marc_os - 16 Jun 2019, 15:34.


--------------------
-----------------
--JE-------SUIS--
--AHMED-CHARLIE--
--CLARISSA-YOAV--
-----------------
Go to the top of the page
 
+Quote Post
SartMatt
posté 16 Jun 2019, 15:39
Message #18


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (marc_os @ 16 Jun 2019, 16:20) *
Citation (SartMatt @ 16 Jun 2019, 13:47) *
Citation (marc_os @ 16 Jun 2019, 13:27) *
La documenation d'APFS ne contient pas d'introduction aussi lisible, mais on peut quand même en déduire un certain nombre de choses:

CODE

typedef int64_tpaddr_t;
// Negative numbers arenʼt valid addresses.
// This value is modeled as a signed integer to match IOKit.

struct prange
{
paddr_t pr_start_paddr;
uint64_t pr_block_count;
};
Ça veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets. Donc je dirais qu'APFS semble bien taillé pour exploiter au mieux les SSD.
Pour moi ça veut plutôt dire que APFS gère l'adressage sur 64 bits.
Je ne voit rien dans ce que tu donnes qui fasse référence à la taille des secteurs (= blocs physiques). Uniquement la taille des adresses et le nombre de blocs (et on ne sait pas s'il s'agit des blocs physiques ou des blocs logiques du système de fichiers, ces derniers ayant à priori par défaut une taille de 4 Ko en APFS).
La structure prange décrit un ensemble de blocs consécutifs (secteurs ou unités d'allocation), avec une adresse de départ sur 64 bits et un nombre de blocs sur 64 bits.
Ai-je dit autre chose ?
Oui, tu as dit que "peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets". Donc que la taille des blocs est de 64 bits (un bloc physique tous les 64 bits, ça veut bien dire que chaque bloc fait 64 bits...).

Or là, c'est quand même clairement la taille des adresses qui fait 64 bits, pas la taille des blocs, et dans les informations que tu cites il n'y a strictement aucune information qui fasse référence à une taille de bloc... La taille des adresses renseigne sur le nombre de blocs adressables, pas sur la taille des blocs.

Si les blocs font 512 octets avec des adresses de 64 bits, en reprenant tes termes, on "peut accéder à des blocs physiques tous les 4096 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets". Et on peut gérer un total de 2^64 de ces blocs (enfin 2^63 ici, puisqu'ils utilisent des entiers signés tout en interdisant les adresses négatives).

En résumé : addresses de 64 bits (ce que je dis) <> adressage par blocs de 64 bits (ce que tu dis).

De plus, comme je l'ai dit, dans ce que tu cites, rien ne dit que ces adresses définies dans ce bout de code sont des adresses physiques (alors que toi tu dis clairement que ça correspond à la taille des blocs physiques), ça peut aussi être des adresses logiques au sein du système de fichier, puisque quasiment tous les systèmes de fichiers fonctionnent uniquement avec des adresses logiques, relatives à la partition, ce qui permet par exemple de cloner une partition vers une autre ou de déplacer une partition sur un disque, alors que les adresses physiques ne sont plus les mêmes.

Et quand on voit que les en-têtes des blocs logiques du APFS font 64 octets, ça serait assez aberrent que le système travaille avec des blocs de 8 octets...

Citation (marc_os @ 16 Jun 2019, 16:20) *
Et bien entendu en, en toute cohérence en me citant tu as viré tu as viré cette phrase :
Quant à l'impact de l'évolution de la norme NVMe sur APFS et ses drivers, à voir, je ne peux rien dire à priori sans étudier plus la chose.
Je n'avais rien à ajouter sur ce point, alors pourquoi le conserver ?
Le conserver ne rendait pas moins fausse la partie sur laquelle je répondais hein...

Citation (marc_os @ 16 Jun 2019, 16:20) *
Citation (SartMatt @ 16 Jun 2019, 13:47) *
Je ne voit rien dans ce que tu donnes qui fasse référence à la taille des secteurs (= blocs physiques). Uniquement la taille des adresses et le nombre de blocs (et on ne sait pas s'il s'agit des blocs physiques ou des blocs logiques du système de fichiers, ces derniers ayant à priori par défaut une taille de 4 Ko en APFS).
Analyser le reste de la documentation d'Apple ça non.
Mais émettre des à priori, de ton propre aveu, ça oui.
Ce n'est pas un simple à priori hein. Si tu ouvrais un peu tes yeux, tu verrais que sous le "4 Ko", j'ai mis un lien. Parce que oui, mon cher, j'ai fait des recherches.
Je n'ai pas trouvé la taille des unités d'allocation d'APFS dans les documentations Apple.

Alors j'ai mis ce que j'ai pu trouver, un article de bloc assez détaillé sur le sujet, fait par quelqu'un qui a étudié APFS en profondeur, et qui dit que la taille des blocs logiques semble être par défaut de 4 Ko.

Mais bon, comme d'hab, tu préfères faire des procès d'intention sur la forme plutôt que de te concentrer sur le fond... Jusqu'à signaler les fautes de grammaire... ben oui, c'est tellement plus facile que d'argumenter sur le fond...

Pourtant, c'est bien une réflexion sur le fond qui t'aurais pourtant peut-être permis de comprendre ta confusion entre taille des blocs et taille des adresses...


--------------------

Go to the top of the page
 
+Quote Post
marc_os
posté 16 Jun 2019, 15:43
Message #19


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 376
Inscrit : 21 Apr 2006
Membre no 59 799



Citation (SartMatt @ 16 Jun 2019, 15:39) *
Citation (marc_os @ 16 Jun 2019, 16:20) *
Citation (SartMatt @ 16 Jun 2019, 13:47) *
Citation (marc_os @ 16 Jun 2019, 13:27) *
La documenation d'APFS ne contient pas d'introduction aussi lisible, mais on peut quand même en déduire un certain nombre de choses:

CODE

typedef int64_tpaddr_t;
// Negative numbers arenʼt valid addresses.
// This value is modeled as a signed integer to match IOKit.

struct prange
{
paddr_t pr_start_paddr;
uint64_t pr_block_count;
};
Ça veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets. Donc je dirais qu'APFS semble bien taillé pour exploiter au mieux les SSD.
Pour moi ça veut plutôt dire que APFS gère l'adressage sur 64 bits.
Je ne voit rien dans ce que tu donnes qui fasse référence à la taille des secteurs (= blocs physiques). Uniquement la taille des adresses et le nombre de blocs (et on ne sait pas s'il s'agit des blocs physiques ou des blocs logiques du système de fichiers, ces derniers ayant à priori par défaut une taille de 4 Ko en APFS).
La structure prange décrit un ensemble de blocs consécutifs (secteurs ou unités d'allocation), avec une adresse de départ sur 64 bits et un nombre de blocs sur 64 bits.
Ai-je dit autre chose ?
Oui, tu as dit que "peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets".

Donc que la taille des blocs est de 64 bits.

FAUX !

C'est TA conclusion, pas la mienne !

Et pourtant j'ai bien écrit noir sur blanc que je ne voulais tirer aucune conclusion.
Mais bon, avec ta mauvaise foi, c'est comme pisser dans violon.
Allez ciao pour de bon, again je te laisse avec tes certitudes et tes À PRIORI.

Ce message a été modifié par marc_os - 16 Jun 2019, 15:44.


--------------------
-----------------
--JE-------SUIS--
--AHMED-CHARLIE--
--CLARISSA-YOAV--
-----------------
Go to the top of the page
 
+Quote Post
SartMatt
posté 16 Jun 2019, 15:50
Message #20


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (marc_os @ 16 Jun 2019, 16:43) *
FAUX !

C'est TA conclusion, pas la mienne !
Alors tu t'es particulièrement mal exprimé.

Par définition, un bloc physique, ou secteur, est la plus petite unité adressable sur un support physique, et tout opération de lecture ou écriture se fait sur une taille multiple de la taille d'un secteur.

Toi tu dis que "APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets".".

Donc tu affirmes que APFS peut gérer un support sur lequel il y a un bloc physique tous les 8 octets. Donc un support dont les blocs physiques font 8 octets (oui, là effectivement j'extrapole, on pourrait avoir un support avec un bloc tous les 8 octets mais des blocs plus petits, avec des trous entre les blocs... tu conviendras que ce serait un peu idiot quand même). Et tu confirmes cette position en affirmant que la taille des données échangées est un multiple de 8 octets.

Nulle part tu ne parles de taille d'adresse, tu ne parles que de taille des données. Et pourtant, le code que tu cites, les tailles qu'il défini sont uniquement des tailles d'adresses, pas des tailles de données. Et il n'y a aucune relation directe entre taille des adresses et taille des données. Et encore, même pour les tailles d'adresses, ce n'est même pas sûr qu'elles font réellement 64 bits : ce n'est pas parce qu'on stocke les adresses dans un int 64 bits qu'on peut forcément vraiment gérer des adresses de 64 bits, ça veut juste dire qu'on gère des adresses de plus de 32 bits... on en a un exemple criant avec nos actuels processeurs 64 bits, ils travaillent tous avec des adresses mémoire stockées dans des champs de 64 bits, mais ils ne travaillent jamais réellement avec des adresses mémoire de 64 bits, la taille réelle des adresses mémoire est de 48 à 52 bits sur les x86-64, 48 bits sur les ARM 64, 56 bits sur les Power 64... mais je digresse là)

Ce que dit le code que tu cites, c'est uniquement que APFS peut accéder grand maximum à 2^63 blocs. On ne sait même pas si le code que tu cites est relatif aux blocs physiques ou aux blocs logiques.


--------------------

Go to the top of the page
 
+Quote Post
marc_os
posté 16 Jun 2019, 16:03
Message #21


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 376
Inscrit : 21 Apr 2006
Membre no 59 799



Citation (SartMatt @ 16 Jun 2019, 15:50) *
Citation (marc_os @ 16 Jun 2019, 16:43) *
FAUX !

C'est TA conclusion, pas la mienne !
Alors tu t'es particulièrement mal exprimé.

Je ne me suis pas mal exprimé, je ne me suis pas exprimé du tout concernant APFS.
Ce qui me semblait évident par contre, c'est que si les structures de données d'APFS peuvent adresser des blocs de 8 octets, alors APFS peut accéder au "disque" tous les 512 octets, tous les 4K, ou ce qu'on veut qui est un multiple de 8 octets.
S'il y a des limitations ou contraites dues à APFS, alors elles sont ailleurs, et il faut se tapper toute la documentation pour le svaoir, ce que je n'ai pas fait, ni toi non plus trop pressé à me contredire.
Je n'ai voulu tirer aucune conclusion, je le répète, quant à l'impact sur APFS de l'évolution de la norme NVMe sans avoir étudié la chose plus en détail.
Mais là j'ai autre chose à foutre que de causer avec tes à prioris.
Ciao pour de vrai ce coup ci.

Ce message a été modifié par marc_os - 16 Jun 2019, 16:05.


--------------------
-----------------
--JE-------SUIS--
--AHMED-CHARLIE--
--CLARISSA-YOAV--
-----------------
Go to the top of the page
 
+Quote Post
SartMatt
posté 16 Jun 2019, 16:09
Message #22


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 125
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (marc_os @ 16 Jun 2019, 17:03) *
Citation (SartMatt @ 16 Jun 2019, 15:50) *
Citation (marc_os @ 16 Jun 2019, 16:43) *
FAUX !

C'est TA conclusion, pas la mienne !
Alors tu t'es particulièrement mal exprimé.

Je ne me suis pas mal exprimé, je ne me suis pas exprimé du tout concernant APFS.
Donc quand tu dis "APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets et que la taille des données échangée est un multiple de 8 octets", tu ne t'exprimes pas du tout concernant APFS ? Ben dis donc rolleyes.gif

Ah au fait, je te rappelle aussi une petite histoire de paille et de poutre dans des yeux : "APFS peut accéder à des blocks physiques tous les 64 bits, soit tous les 8 octets, et que la taille des données échangées est un multiple de 8 octets"
Comme ça tu pourras encore une fois jouer sur la forme pour éluder le fond.

Citation (marc_os @ 16 Jun 2019, 17:03) *
Ce qui me semblait évident par contre, c'est que si les structures de données d'APFS peuvent adresser des blocs de 8 octets
D'où sors tu que APFS peut adresser des blocs de 8 octets ? Le bout de code que tu cites et dont tu sembles déduire ce chiffre de 8 octets ("on peut quand même en déduire un certain nombre de choses", puis bout de code puis "ce qui veut dire qu'APFS peut accéder à des blocks physiques tous les 64 bits") ne parle absolument pas de taille de blocs, il parle uniquement de taille d'adresses (effectivement, adresses physiques, ce n'est pas inclus dans ce que tu cites, mais en cherchant dans la doc prange_t est bien documenté comme étant "A range of physical addresses"). Je veux bien croire que APFS peut gérer des blocs physiques de 8 octets, ce serait une bonne chose pour gérer les futures supports de stockage à base de RAM non volatile, si ces supports restent sur le même schéma d'adressage que la RAM classique. Mais le bout de code que tu cites et dont tu sembles déduire cette taille de 8 octets, il ne prouve absolument rien à ce niveau, puisqu'il ne parle que de la taille des adresses.

Et il n'y a aucun lien entre la taille des adresses physiques et celle des blocs. Ce n'est pas parce que les adresses font 8 octets que les blocs font 8 octets. Je ne saurai d'ailleurs pas citer un support de stockage actuel où la taille des adresses est égale à la taille des blocs physiques... Le cas où on est le plus proche, c'est la RAM, où effectivement on a actuellement en théorie du point de vue des fabricants de DRAM des adresses 64 bits et des blocs de 64 bits, mais en pratique, du point de vue des processeurs, on a des adresses de l'ordre de la cinquantaine de bits et des blocs de n*64 bits avec n le nombre de canaux mémoire gérés en parallèle, n étant compris entre 2 et 4 sur le gros des processeurs modernes. Pour les disques durs, on a eu d'abord des adresses "3 dimensions" sur 24 bits (cylindre sur 10 bits, tête sur 8 bits, secteur sur 6 bits), puis des adresses "1 dimension" de 22, 28 et enfin 48 bit (tu te souviens peut-être de l'arrivée des premiers disques durs de plus de 137 Go, pas compatibles avec certaines machines ? c'est parce qu'il fallait une machine gérant les adresses 48 bits, introduites en 2003, les machines antérieures étant limitées à 137 Go par l'adressage 28 bits), avec des blocs physiques de 512 o puis 4 Ko.

Bref, la taille d'un bloc peut être proche de celle de l'adresse dans certains cas, elle peut aussi être très supérieure dans d'autres, mais il n'y a aucune raison qu'elle soit identique à priori. Ni même que la taille minimale d'un bloc soit la même que celle d'une adresse. En effet, puisqu'il n'y a aucun lien entre les deux, rien n'empêche de faire des adresses plus grandes que les blocs, si ce n'est le fait que ce n'est pas pratique du tout (on a alors besoin de plusieurs blocs si on veut stocker l'adresse d'un bloc !). Ça a même été très courant pendant dans l'histoire du PC : les processeurs Intel 8086, 8088, 80186 et 80286 et leurs clones accédaient à la mémoire par blocs de 16 bits adressés sur 20 ou 24 bits. L'adressage 16 bits avec des blocs de 2 octets limitait en effet la quantité de mémoire à 128 Ko (2^16 * 2 octets), le passage à 20 puis 24 bits permettant de monter à 2 puis 32 Mo sans avoir à apporter d'importantes modifications à l'architecture du CPU pour gérer des blocs plus gros (le 80386 est ensuite passé à des blocs de 32 bits et des adresses de 32 bits, puis le Pentium à des blocs de 64 bits tout en gardant les adresses 32 bits, d'où l'obligation à l'époque de monter les barrettes de mémoire EDO par deux, car ces barrettes avaient des blocs de 32 bits, c'est seulement avec l'arrivée de la SDRAM qu'on a eu des blocs de 64 bits au niveau des barrettes). Dans une certaine mesure, on peut même considérer que c'est le cas de toutes les RAM, car même si la taille minimale des données lues où écrites est contrainte par la taille du bus mémoire (n*64 bits aujourd'hui, comme dit plus haut), les adresses sont en fait toujours à l'octet près et la RAM répond avec l'ensemble de 8 blocs contenant l'adresse demandées et dont les adresses sont comprises entre 8*adresse//8 et 8*adresse//8 + 7 : si on demande les données à l'adresse 2 ou à l'adresse 3, on va recevoir strictement la même chose sur le bus mémoire, à savoir les données qui sont dans les blocs d'adresse 0 à 7.

C'est pareil qu'avec La Poste, la taille de la boîte aux lettres n'est pas égale à la taille de l'adresse laugh.gif Et on serait aussi bien emmerdé si nos boîtes mails ne faisaient pas plus que les quelques dizaines d'octets correspondant à la taille de leur adresse laugh.gif

Ce message a été modifié par SartMatt - 16 Jun 2019, 16:52.


--------------------

Go to the top of the page
 
+Quote Post
vlady
posté 16 Jun 2019, 17:48
Message #23


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 875
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



La structure est nommé "range". En général range souvent employé pour indiquer une partie d'une collection. Il y a un début (l'adresse de début) et le nombre d'élément faisant partie de range. Pour la taille des éléments, il faut avoir plus de détails. Voici le code qui implique la structure prange_t :

CODE

for (int i = 0; i < jumpstart->nej_num_extents; i++) {
prange_t efi_extent_address = jumpstart->nej_rec_extents[i];
for (int j = 0; j < efi_extent_address.pr_block_count; j++) {
void* efi_block = read_block(efi_extent_address.pr_start_paddr + j);
memcpy(efi_driver_cursor, efi_block, superblock->nx_block_size);
efi_driver_cursor += superblock->nx_block_size;
}
}


la ligne

memcpy(efi_driver_cursor, efi_block, superblock->nx_block_size);

indique que la taille du block est => superblock->nx_block_size

qui n'est pas forcement la taille d'adresse (64bit). Bref, ici j'ai l'impression que les adresses dans la structure prange_t ce sont juste des débuts des blocks.

Ce message a été modifié par vlady - 16 Jun 2019, 18:02.


--------------------
Mac Pro late 2013 Xeon Quad 3.7GHz/16GB, écran Eizo EV2736W, Mac Book Air 11" 1.6GHz/4GB, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
chammer
posté 16 Jun 2019, 18:18
Message #24


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 340
Inscrit : 16 May 2002
Membre no 2 488



Pour éviter les disputes, les données sont les suivantes :

- le nombre maximum de blocks adressables est 2^56. C'est bien en 64 bits, mais on a besoin des 8 derniers bits pour les nodes B-tree.
- la taille *minimale requise* des blocks est de 4kiB. Cela a d'ailleurs posé des problèmes avec certains SSD. On peut monter actuellement à 64kiB. La valeur est définie à l'offset 0X24 du Container Super Block et se choisit avec l'utilitaire newfs_apfs -b.


--------------------
"Je vais mettre Mouse Office pour voir combien de kilomètres je parcours entre 2 changements de scotch et nettoyage de boule.
Même dans le domaine du petit bricolage, il faut savoir rester rigoureux. :-) "
-+- CH in Guide du Macounet Pervers : Bien bricoler sa souris -+-
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 5th December 2019 - 19:26