NVMe : simple perfectionnement, ou prémice d’une révolution ?
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.