Une autre fonctionnalité qui doit être envoyée pour la prochaine fenêtre de fusion du noyau Linux 6.5 est l’introduction de la prise en charge des primitives de provisionnement pour le stockage finement provisionné avec le code Device Mapper (DM).
Une branche créée au cours du week-end était dm-6.5-provision-support de linux-dm.git. Avec elle maintenant sur une branche marquée pour”6.5″, semble positionnée pour être envoyée pour la prochaine fenêtre de fusion Linux 6.5, empêchant tout problème d’être soulevé par Linus Torvalds ou d’autres développeurs du noyau.
Ces primitives de provisionnement ont été élaborées par l’équipe Chrome OS de Google. Sarthak Kukreti de Google a précédemment expliqué cette initiative dans les précédents correctifs RFC sur le mailing list :
“Cette série de correctifs est une RFC d’un mécanisme permettant de transmettre les demandes de provisionnement sur des périphériques de stockage/systèmes de fichiers empilés à provisionnement fin.
Le noyau Linux fournit plusieurs mécanismes pour configurer des abstractions de stockage de blocs à provisionnement fin ( par exemple, dm-thin, périphériques en boucle sur des fichiers épars), soit directement en tant que périphériques de bloc, soit en tant que stockage de sauvegarde pour les systèmes de fichiers. Actuellement, à moins d’écrire des données sur le périphérique ou le système de fichiers, il n’y a aucun moyen pour les utilisateurs de pré-allouer de l’espace à utiliser dans de telles configurations de stockage. Considérez les cas d’utilisation suivants :
1) Suspension sur disque et reprise à partir d’un périphérique dm-thin : afin de garantir que les métadonnées du thinpool sous-jacent ne sont pas modifiées pendant le mécanisme de suspension, le périphérique dm-thin doit être entièrement provisionné.
2) Si un système de fichiers utilise un périphérique de boucle sur un fichier fragmenté, fallocate() sur le système de fichiers allouera des blocs pour les fichiers mais le fichier fragmenté sous-jacent restera intact.
3) Un autre exemple est une machine virtuelle utilisant un fichier sparse/dm-thin comme périphérique de stockage ; par défaut, les allocations dans les limites de la machine virtuelle n’affecteront pas l’hôte.
4) Plusieurs normes de stockage prennent en charge des mécanismes de provisionnement léger sur des périphériques matériels réels. Par exemple :
a. La section 2.1.1 de la spécification NVMe 1.0b parle vaguement du provisionnement fin :”Lorsque le bit THNP dans le champ NSFEAT de la structure de données d’identification de l’espace de noms est défini sur’1′, le contrôleur… doit suivre le nombre de blocs alloués dans le champ Utilisation de l’espace de noms”
b. La référence des commandes de bloc SCSi-4 sections fait référence aux”unités logiques à provisionnement léger”,
c. La section 13.3.3 de la spécification UFS 3.0 fait référence au”provisionnement léger”.Dans toutes les situations ci-dessus, actuellement le seul moyen de pré-allouer de l’espace est d’émettre des écritures (ou d’utiliser WRITE_ZEROES/WRITE_SAME). Cependant, cela ne s’adapte pas bien aux tailles de pré-allocation plus importantes.
Ce patchset introduit des primitives pour prendre en charge les requêtes de provisionnement au niveau du bloc (remarque : le terme « provisionnement » est utilisé pour éviter de surcharger le terme « allocations/pré-allocations ») sur les systèmes de fichiers et les périphériques de bloc. Cela permet à fallocate() et aux requêtes de création de fichiers de réserver de l’espace sur des couches empilées de périphériques de blocs et de systèmes de fichiers. Actuellement, le patchset couvre un prototype sur les cibles de mappeur de périphériques, périphérique de boucle et ext4, mais le même mécanisme peut être étendu à d’autres systèmes de fichiers/périphériques de bloc ainsi que étendu pour une utilisation avec des périphériques en 4 a-c.”
Le correctif introduisant la requête REQ_OP_PROVISION résume simplement ce provisionnement comme :
“Introduire la requête de bloc REQ_OP_PROVISION. L’intention de cette demande est de demander au stockage sous-jacent de préallouer de l’espace disque pour la plage de blocs donnée. Les périphériques de blocage qui prennent en charge cette fonctionnalité exporteront une limite de provisionnement dans leurs files d’attente de requêtes.
Ce correctif ajoute également la possibilité d’appeler fallocate() en mode 0 sur les appareils en mode bloc, ce qui enverra REQ_OP_PROVISION à l’appareil en mode bloc pour la plage spécifiée,”
Ce bloc provisionne les primitives Le travail est en préparation depuis plusieurs mois et a été testé avec succès sur Chrome OS et sur le noyau Linux en amont. Les modifications de bloc et de DM autour de REQ_OP_PROVISION ainsi que la prise en charge du périphérique de bouclage pour celui-ci sont maintenant sur le point d’apparaître dans Linux 6.5.
La fenêtre de fusion de Linux 6.5 devrait commencer la semaine prochaine si la version stable de Linux 6.4 n’est pas repoussée d’une semaine supplémentaire. La version stable de Linux 6.5 devrait à son tour faire ses débuts vers la fin du mois d’août.
