Résumé

  • Le texte du 26 septembre reste un Internet-Draft actif du groupe NFSv4, et non une norme publiée en RFC.
  • Sa nouvelle section pNFS précise qu’un client diligent peut recevoir une taille dépassée si le serveur de métadonnées n’a pas encore appris l’écriture effectuée sur un dispositif de stockage.

Dans un répertoire partagé par de nombreux nœuds de calcul, un fichier peut grossir sans que le répertoire change de nom, de composition ou d’attribut de changement. Un outil qui parcourt le répertoire pour déterminer quels fichiers copier peut alors faire confiance à une ancienne taille gardée par son client NFS. Le projet propose un attribut booléen attaché au répertoire : lorsque le serveur l’active, le client qui le respecte doit faire un nouveau READDIR à chaque parcours et ne doit pas réutiliser des attributs d’entrée obtenus avant le READDIR qui vient de fournir cette entrée.

Ce remède vise une mémoire précise, celle des métadonnées d’entrée de répertoire. Il ne désactive pas la mise en cache des données du fichier ni celle de l’objet répertoire. Son principe figurait déjà dans la révision 11 datée du 5 septembre. La révision 12 décrit plus nettement pourquoi les deux composantes sont nécessaires : un READDIR qui ne demande presque aucun attribut, suivi de l’affichage d’anciennes valeurs locales, ne satisferait pas l’intention. Le client peut demander les attributs dans READDIR ou les obtenir ensuite, au prix éventuel d’un GETATTR par entrée.

Le coût de réseau et la précision demandée restent donc à arbitrer par les exploitants.

La nouveauté qui change le diagnostic figure dans la section 5.2. Avec pNFS, le répertoire et son attribut relèvent du serveur de métadonnées, tandis que les écritures de données peuvent passer par un dispositif de stockage distinct. Pour une disposition où le serveur de métadonnées ne connaît la nouvelle taille et la nouvelle date de modification qu’au moment de LAYOUTCOMMIT, un READDIR effectué avant ce moment renvoie les anciennes valeurs. Le client qui rapporte ces valeurs n’a pas violé la règle. Il ne pouvait pas extraire de son interlocuteur une information que cet interlocuteur ne possédait pas encore.

Il importe de ne pas transformer cet exemple conditionnel en loi générale sur tous les systèmes pNFS. Le comportement dépend du type de disposition et de la manière dont les changements de métadonnées remontent. Le projet n’établit ni lecture instantanée de toutes les écritures ni photographie cohérente de l’ensemble du répertoire. Il réduit une source de décalage, celle du cache client, sans abolir celle qui peut exister entre stockage et serveur de métadonnées.

Le même texte éclaire une autre limite, administrative. Le serveur peut connaître l’attribut tout en refusant qu’un utilisateur le règle. La nouvelle rédaction impose alors NFS4ERR_ACCESS, ou NFS4ERR_PERM dans le cas de propriété ou de privilège précisé, plutôt que NFS4ERR_INVAL. Cette dernière réponse signifie, pour une sonde de prise en charge, que le serveur ignore l’attribut. Confondre refus et absence de fonctionnalité empêcherait de savoir si la correction passe par les droits, la configuration ou la compatibilité logicielle.

Le registre officiel classe toujours le document parmi les projets actifs, à l’état « I-D Exists ». La mention d’un serveur Hammerspace et d’un client Linux prototypes n’établit ni diffusion générale ni garantie de résultat pour les sauvegardes. Le texte décrit des obligations proposées pour les systèmes qui choisissent de les mettre en œuvre.

Sources