Forum de l’article

NVMe : simple perfectionnement, ou prémice d’une révolution ?

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
NVMe : simple perfectionnement, ou prémice d’une révolution ?
Frédéric LOYER - le 18 septembre 2020

Sauf erreur de ma part, NVMe sert à échanger des commandes de lectures/écritures de blocs. Comme le font SATA ou SCSI. Peut-être différemment (on écrit dans les registres du contrôleur comme on écrit en mémoire via le bus PCIe), plus rapide, plus élaboré (plusieurs queues parallèles), mais on est loin d’un accès mémoire comme le fait un CPU. Mais peut-être que je me trompe.
Par ailleurs, le problème de l’interface (SATA/SCSI/NVMe/mémoire vive) me semble à décoreller de la gestion.

Se passer d’un système de fichier est déjà accessible avec les vielles interfaces : un mmap sur l’ensemble du disque est théoriquement possible et l’on a un accès à l’ensemble des données persistantes via des accès mémoire. (En pratique se pose les questions des performances et de la gestion des droits)
Les questions pour se passer du système de fichiers sont multiples : quel degré de finesse vise t-on (est-on optimisé pour une myriade d’unités nommées de 4 octets ?), quels services (indexation, gestion des transactions...), quel interface avec le langage (Python permet de définir un objet avec une méthode __getattr__ appelée dès qu’un attribut n’est pas trouvé et pourrait se retourner vers la mémoire permanente pour trouver une valeur de façon transparente pour le développeur... mais sans cache, ce serait peu optimum, plusieurs langages permettent d’avoir des tableaux associatifs mappés sur des fichiers base de données : natif dans Perl, mais la surcharge de l’opérateur [] dans plusieurs langages permet de faire de même...).
Toutes ces questions (et les développements qui vont avec), vont bien au delà de la chaîne de transmission CPU-mémoire permanente.