Discussion :

[plxpy]

Bonjour

petites questions sur les inodes et les liens (et tout au long de ce que j'écris, quand j'écris lien il s'agit bien des liens hards : plusieurs noms/chemins pour un même inode, au sein, forcément, du même système de fichiers)

- comment récupérer tous les liens d'un même inode, autrement qu'en parcourant l'arborescence du SF et en cherchant (via stat) le numéro d'inode (ce qui peut être un peu longuet ...) ? Je crains qu'il n'y ait pas de solution ...

- quelle est la limite de nombre de liens ?
Pour du ext4 sous Ubuntu, c'est rideau après 65000 liens sur une même inode (65 000 ??? et pas 65536 - quelques uns).
Pour du HFS (Mac/Apple), c'est 32767 qui fleure bon le 2^15-1 (mais pourquoi 15 et pas 16, pourquoi -1 ?)
Est-ce un paramètre à spécifier lors de la création du SF ?
Est-ce lié à la taille du compteur de liens au niveau de l'inode (2 octets -> 16 - 1 -> 2^15-1 pour HFS mais pour ext4 ... ) ?

précisions sur le contexte : mon intérêt sur ces limites n'est pas gratuit. il s'agit de gérer plusieurs versions de "produits", chaque produit est une arborescence de fichiers et correspond à un degré carré sur notre bonne vieille Terre. Donc 360 x 180 = 64800 arborescences, pour 1 seule version.

[gangsoleil]

Bonjour,

Je ne sais pas forcement bien repondre a tes questions, mais j'ai une idee la dessus :

32767 qui fleure bon le 2^15-1 (mais pourquoi 15 et pas 16, pourquoi -1 ?)

Tout simplement parceque c'est code sur un entier signe (ce qui n'apporte rien, mais ce n'est pas le debat).

[plxpy]

Merci de ta réponse mais j'avais bien intuité que ça devait être stocké sous un short (signé).

Mais le fait de ne pas utiliser les 16 bits pour quelque chose qui ne peut être négatif (et, dans ce cas précis, non nul, mais là c'est plus dur à gérer et, à quoi bon) est "un peu" crétin (un peu comme si on gérait la taille des fichiers, dans les structures stat comme des valeurs signées !).

SAUF si quelque chose m'échappe. En plus, le nombre de liens c'est, j'en suis persuadé, stocké au niveau de l'inode (dans le noyau), donc les gens qui codent ça ne sont pas des programmeurs du dimanche !

Par contre, le 65000 de ext4 me laisse toujours sans voix !

[Obsidian]

Mais le fait de ne pas utiliser les 16 bits pour quelque chose qui ne peut être négatif (et, dans ce cas précis, non nul, mais là c'est plus dur à gérer et, à quoi bon) est "un peu" crétin (un peu comme si on gérait la taille des fichiers, dans les structures stat comme des valeurs signées !).

Malheureusement — et sans tirer de conclusions hâtives sans fondement avéré (c'est comme ça que partent les rumeurs) — il a de moins en moins de programmeurs qui soient encore vraiment proches de leur machine et de ce genre de considérations. Par exemple, en Java, les entiers sont forcément signés. Donc, quiconque a pris l'habitude dès le départ de programmer sans se soucier des questions de type aura beaucoup de mal à les prendre en considération s'il n'y est pas directement confronté à cause d'un problème technique.

SAUF si quelque chose m'échappe. En plus, le nombre de liens c'est, j'en suis persuadé, stocké au niveau de l'inode (dans le noyau), donc les gens qui codent ça ne sont pas des programmeurs du dimanche !

Pour Apple/HFS, je ne sais pas. Apple fait de bons produits (si, si), mais il est de fait qu'ils restent très obscurs et qu'à l'époque (il y a une petite quinzaine d'années) on m'avait déjà dit qu'ils avaient un « core pouilleux », chose que je n'ai jamais pu vérifier par moi-même.

Cela dit, comme la production de leur machines comme de leur système est étroitement contrôlée, il serait étonnant qu'ils n'en profitent pas pour faire des raccourcis et des optimisations de très bas niveau dédiées aux machines cibles.

Pour le « -1 », c'est parce que c'est la valeur maximum. Idem sur 16 bits, on peut compter de 0 à 2¹⁶-1.

Cela dit, j'imagine que l'explication la plus probable est justement pour se laisser la possibilité de coder des valeurs « hors-domaine » inférieures à zéro (codes d'erreur, marqueur NULL, NaN…).

Par contre, le 65000 de ext4 me laisse toujours sans voix !

'faudrait demander à Rémi Card.

Mais là encore, je pense que c'est justement, comme tu l'évoques par « 65536 - quelques uns », pour réserver une plage pour les codes d'erreur de manière un peu plus intelligente et suffisamment large pour pouvoir évoluer (rajouter des codes ultérieurement) sans avoir à modifier les spécifications du FS à chaque révision, tout en choisissant une limite psychologique aisée à retenir. Ce serait ennuyeux qu'un programme comme le tien qui exploite autant de liens durs ne puisse plus fonctionner sur EXT5.

Enfin, cela dit, c'est quand même sauvage de mettre 65000 liens durs sur un même fichier. Il serait quand même plus intéressant de résoudre logiciellement tes coordonnées à l'aide d'une petite fonction qui, elle, te renverrait le nom du package adéquat.

précisions sur le contexte : mon intérêt sur ces limites n'est pas gratuit. il s'agit de gérer plusieurs versions de "produits", chaque produit est une arborescence de fichiers et correspond à un degré carré sur notre bonne vieille Terre. Donc 360 x 180 = 64800 arborescences, pour 1 seule version.

Tu fais un simulateur de vol ? :-)

[plxpy]

Tu fais un simulateur de vol ? :-)

Pas du tout. En fait il s'agit de développer des outils pour utiliser (lecture/écriture/mise à jour) une archive de produits avec gestion des versions des données.

Chaque produit est une arborescence de fichiers (format imposé) mélant :

• des données géographiques (images satellite et/ou MNT (Modèles Numériques de Terrain))
• des tas de masques sur ces données (qualité, masque Terre-Mer, images origine, etc..)
• des tas de métadonnées
• des fichiers permettant la visualisation du produit sous un navigateur www (html + feuilles de style)

Chaque produit s'étend sur 1 degré-carré et certaines arborescences ne comptent pas moins de 300 fichiers.

Donc, pour avoir toutes les données en ligne, dans le bon format (si possible), dans toutes les versions (jusqu'à une dizaine en fin de vie/production), je dois me préoccuper de ne pas remplir le SF en termes de volume mais aussi en termes de nombres de fichiers.

Donc je voulais exploiter le fait que :

• dans un même produit, entre deux versions, tout ne change pas
• un nombre non négligeable de fichiers sont identiques dans tous les produits, dans toutes les versions

en utilisant les liens hards qui permettraient d'avoir les arborescences standards et de diminuer le nombre d'inodes et la place occupée.

65000 est-ce trop ? Je ne sais pas. Après, une fois que le mécanisme de liens hards existe, qu'il y en ait 10 ou un million ... ce n'est jamais qu'un numéro stocké dans chaque "entry" d'un répertoire (je crois) et qui aboutit à un fichier disque

Ce qui est sur, c'est que ça donnerait une arborescence assez monstrueuse (sans qu'il y ait cependant de problème de profondeur et de chemin absolu, j'ai vérifié).

Là, pour le coup, je n'en ai pas assez. C'est un peu moins de 20 000 degrés carrés qui seront couverts (on s'arrête à +/-80° de latitude et les degrés carrés situés uniquement sur l'eau ne sont pas produits). Donc c'est environ 200 000 liens qui seraient nécessaires pour les fichiers constants qu'on retrouve dans tous les produits, quelle que soit la version.

Je pense de toute façon laisser tomber cette approche pour d'autres raisons (droits d'accès au travers du réseau qui permettent de créer/détruire des fichiers sur le volume mais la commande ln refuse obstinément de fonctionner ?!)

[Obsidian]

65000 est-ce trop ? Je ne sais pas. Après, une fois que le mécanisme de liens hards existe, qu'il y en ait 10 ou un million ... ce n'est jamais qu'un numéro stocké dans chaque "entry" d'un répertoire (je crois) et qui aboutit à un fichier disque

C'est-à-dire qu'à chaque fichier est associé un i-node qui, lui, cèle plusieurs informations le concernant comme, notamment, le nombre de liens durs qui le référencent. Ensuite, les entrées dans le catalogue se réfère qu'à un numéro d'i-node. Celui-là même que l'on voit avec « ls -i ».

Il fut un temps où le nombre total d'inodes était très limité, ce qui causait des cheveux blancs aux admins système. Ce n'est plus le cas depuis longtemps, par contre la taille des inodes eux-mêmes est toujours surveillée, spécialement s'il doit y avoir autant d'inodes que de fichiers. Par conséquent, il n'est pas irrationnel d'utiliser un champ de 16 bits pour compter les liens durs. C'est ce que j'aurais fait aussi.

Ce qui est sur, c'est que ça donnerait une arborescence assez monstrueuse (sans qu'il y ait cependant de problème de profondeur et de chemin absolu, j'ai vérifié).

Ok, mais, là encore, t'es-t-il vraiment impossible d'utiliser une application, un RPC, ou un web service quelconque pour te donner le nom et le chemin du bon fichier, plutôt qu'essayer de les référencer directement ?

Je pense de toute façon laisser tomber cette approche pour d'autres raisons (droits d'accès au travers du réseau qui permettent de créer/détruire des fichiers sur le volume mais la commande ln refuse obstinément de fonctionner ?!)

C'est normal : un lien dur est une entrée du catalogue qui se réfère à un inode. Il est donc obligatoire que l'un et l'autre se trouvent sur le même système de fichiers.

Par contre, tu dois tout-à-fait pouvoir utiliser les liens symboliques. Moi je mixerais les deux, d'autant que tu peux faire des liens durs sur des liens symboliques.

[plxpy]

Déjà, pour fixer les choses :

• ca tourne[ra] sous MacOSX, Snow Leopard (puis Lion)
• le système de fichiers est ACFS (Apple Clustered File System, que je ne connaissais pas il y a une semaine de cela) sur un Xsan(2), le volume faisant 20 Toctets

et je coderai tout ça en Python, sans m'interdire de faire appel directement à une commande Unix (os.system()) ou à un exécutable écrit spécifiquement, en C, si besoin.
La portabilité entre OS n'est pas demandée et est la dernière de mes préoccupations.

C'est normal : un lien dur est une entrée du catalogue qui se réfère à un inode. Il est donc obligatoire que l'un et l'autre se trouvent sur le même système de fichiers.

Je sais qu'un lien hard ne peut se faire qu'au sein d'un même SF (cf message #1). Je ne pense pas que ce soit ça qui soit en cause ici. Ma commande "ln" tente bien de créer un lien au sein d'un même système de fichiers. Je n'ai pas le serveur sous la main mais, de mémoire, le message d'erreur indique "not permitted", "not allowed" ou quelque chose dans le genre. Par contre, si je me loggue directement sur la machine (controleur principal) du XSan, aucun problème.

Je suis d'accord avec toi quand tu dis que Apple fait de bons produits. Mais c'est vrai aussi que la doc ne suit pas trop. Je suis pourtant aguérri vis à vis des droits classiques Unix mais là, entre la couche réseau, la couche Apple, la couche graphique Apple, je me retrouve souvent "comme un con" devant tel ou tel comportement.

Dans ma boite, ça nous pose d'ailleurs de vrais gros problèmes ! Généralement on shunte ça en donnant tous les droits à tout le monde et en donnant des consignes. C'est sur, ce n'est pas très glorieux, mais faut bien avancer !

Ok, mais, là encore, t'es-t-il vraiment impossible d'utiliser une application, un RPC, ou un web service quelconque pour te donner le nom et le chemin du bon fichier, plutôt qu'essayer de les référencer directement ?

les web services : aussi étrange que cela puisse paraitre, par rapport à mon domaine, je n'y entends rien ! Si tu as un lien vers quelque chose qui fait bien la part des choses, je suis preneur (une simple recherche sur Google te ramène des tas de trucs ... mais surtout n'importe quoi).

une application dédiée : c'est ce vers quoi je m'oriente (voir plus bas)

Par contre, tu dois tout-à-fait pouvoir utiliser les liens symboliques.

Je les connais (ils sont plus connus que les liens hards) mais, c'est con, je suis pas copain avec ! Je n'ai aucun argument technique à formuler. Je les trouve utiles quand il s'agit de gérer plusieurs versions d'une bibliothèque, d'un exécutable, mais, pour mon problème, je fais la fine bouche.

Surtout que j'avais pensé aux liens hards pour proposer aux utilisateurs, sous Finder, des produits conformes à la spec. Dès qu'on passe par des liens symboliques, ce n'est plus vrai. Un "drag and drop" d'un répertoire contenant des liens symboliques ...

Vers quoi je m'oriente ?

Dans chaque produit/arborescence, on peut faire des "paquets" :

• ce qui est constant, quel que soit le degré carré ou la version
• des fichiers propres à un degré-carré, quelle que soit la version
• des fichiers qui "évoluent", selon les versions, ensemble (des composants)

Chaque groupe ci-dessus sera stocké sous la forme d'une archive (tar, a priori, sans compression) et chaque produit "versionné" pointera "à la main" (un xml pour ne pas créer un n+1 ième format) sur ses composants. Je n'ai pas encore finalisé l'organisation de tout ce petit monde mais c'est un détail.

ps : merci Obsidian de tes lectures attentives. Mes collègues connaissent moins que moi les aspects systèmes (ils sont plus calés sur d'autres domaines) et donc, pour valider mes "idées", je suis un peuà cours d'avis éclairés.

[Obsidian]

Je sais qu'un lien hard ne peut se faire qu'au sein d'un même SF (cf message #1). Je ne pense pas que ce soit ça qui soit en cause ici. Ma commande "ln" tente bien de créer un lien au sein d'un même système de fichiers. Je n'ai pas le serveur sous la main mais, de mémoire, le message d'erreur indique "not permitted", "not allowed" ou quelque chose dans le genre. Par contre, si je me loggue directement sur la machine (controleur principal) du XSan, aucun problème.

Ok. Dans ce contexte.

J'ai très peu l'habitude des produits Apple, malheureusement. Donc je ne peux pas t'aider directement. Par contre, j'ai eu des problèmes tout-à-fait similaires avec un NFS mal configuré.

Dans ma boite, ça nous pose d'ailleurs de vrais gros problèmes ! Généralement on shunte ça en donnant tous les droits à tout le monde et en donnant des consignes. C'est sur, ce n'est pas très glorieux, mais faut bien avancer !

Hélas, oui. Tout le monde fait cela. Il est vrai qu'il faut trouver un juste milieu entre tout coder à l'arrache et faire sept ans de spécifications dans des classeurs avant d'écrire la première ligne de code (authentique, paraît-il).

les web services : aussi étrange que cela puisse paraitre, par rapport à mon domaine, je n'y entends rien ! Si tu as un lien vers quelque chose qui fait bien la part des choses, je suis preneur (une simple recherche sur Google te ramène des tas de trucs ... mais surtout n'importe quoi).

Oui, enfin, je disais ça dans le principe. Je n'en suis pas fan du tout moi non plus. Je pensais surtout à prendre le problème entièrement dans l'autre sens du fait de ces limitations, c'est-à-dire, pour le coup, ne représenter qu'une seule fois chaque fichier sur le FS et utiliser une base de dépendances ou une petite application dédiée pour « résoudre » le nom de fichier théorique vers le chemin où on le trouvera réellement.

Ce n'est peut-être pas faisable non plus, ça dépend beaucoup de ton contexte, que, bien sûr, je ne peux toujours pas connaître entièrement.

Je les connais (ils sont plus connus que les liens hards) mais, c'est con, je suis pas copain avec ! Je n'ai aucun argument technique à formuler. Je les trouve utiles quand il s'agit de gérer plusieurs versions d'une bibliothèque, d'un exécutable, mais, pour mon problème, je fais la fine bouche.

Je comprends tout-à-fait. Je disais cela parce que ça te permet, d'un point vue mathématique uniquement, de t'affranchir de la limite des 65000 liens (en posant un lien symbolique tous les 65000 liens durs). C'est sûr que ce n'est pas très propre, mais ce n'est pas non plus de la bidouille.

Le problème vient surtout du fait que les gens tendent à les utiliser comme des raccourcis Windows et, du coup, en oublient complètement l'existence des liens durs que l'on ne retrouve pas sous d'autres familles d'OS.

Par ailleurs, les liens symboliques sont (quand même) de vrais fichiers dotés de leur propre inode. Quand on en crée trop, on se retrouve à remplir le FS avec des micro-fichiers comme dans une classe Java. Et encore, celle-ci a quand même le mérite de rassembler le tout dans une archive. En plus, lorsque l'on supprime le fichier cible, le lien devient orphelin.

Par contre, ils ont beaucoup d'avantages : ils permettent de faire un lien vers un répertoire, ils peuvent référencer un autre système de fichiers, ils permettent de faire un renvoi explicite vers une autre cible que l'utilisateur peut voir éventuellement, et le défaut de lien brisé peut aussi être un avantage : s'assurer que le fichier concerné est bien détruit (surtout s'il est important en taille) sans avoir à faire une recherche exhaustive de son inode à travers toute la partition.

Surtout que j'avais pensé aux liens hards pour proposer aux utilisateurs, sous Finder, des produits conformes à la spec. Dès qu'on passe par des liens symboliques, ce n'est plus vrai. Un "drag and drop" d'un répertoire contenant des liens symboliques ...

Hmm, ça c'est peut-être une faiblesse d'Apple, alors. Une copie récursive d'un répertoire devrait par défaut copier les liens en tant que tel et pas les suivre.

Dans chaque produit/arborescence, on peut faire des "paquets" :

• ce qui est constant, quel que soit le degré carré ou la version
• des fichiers propres à un degré-carré, quelle que soit la version
• des fichiers qui "évoluent", selon les versions, ensemble (des composants)

Chaque groupe ci-dessus sera stocké sous la forme d'une archive (tar, a priori, sans compression) et chaque produit "versionné" pointera "à la main" (un xml pour ne pas créer un n+1 ième format) sur ses composants. Je n'ai pas encore finalisé l'organisation de tout ce petit monde mais c'est un détail.

Justement, en soi, ça ressemble beaucoup aux système de gestion des packages et des logiciels installés sur les différents OS, qui sont confrontés à la fois au versionning, à la gestion des dépendances et à celle des conflits.

Ne peux-tu pas tout simplement utiliser ces formats pour publier le contenu de chaque produit et laisser le système en place gérer le tout, en le laissant installer/télécharger automatiquement les dépendances ?

ps : merci Obsidian de tes lectures attentives. Mes collègues connaissent moins que moi les aspects systèmes (ils sont plus calés sur d'autres domaines) et donc, pour valider mes "idées", je suis un peuà cours d'avis éclairés.

C'est un plaisir.
À ton service.

[D[r]eadLock]

> Par contre, le 65000 de ext4 me laisse toujours sans voix !
'faudrait demander à Rémi Card.

/*
* Maximal count of links to a file
*/
#define EXT4_LINK_MAX 65000

Et encore, avant c'était 32000 (http://www.mail-archive.com/git-comm.../msg17984.html)

>Surtout que j'avais pensé aux liens hards pour proposer aux utilisateurs, sous
> Finder, des produits conformes à la spec. Dès qu'on passe par des liens
> symboliques, ce n'est plus vrai. Un "drag and drop" d'un répertoire contenant
> des liens symboliques ...
Hmm, ça c'est peut-être une faiblesse d'Apple, alors. Une copie récursive d'un répertoire devrait par défaut copier les liens en tant que tel et pas les suivre.

+1: c'est effectivement l'avantage des liens symboliques normalement ils restent symbolique (même dans un tar) !

Sinon, je n'ai pas encore tout pigé entre produit, arborescence, et version (i.e. quels sont les ordres de grandeurs, sauf, version ~10), mais je pense qu'effectivement les symlinks sont plus 'propres':

• permettrait d'archiver
• manipulation plus explicite (comme dit par Obsidian, moins besoin de faire un find -inum)

le message d'erreur indique "not permitted", "not allowed
[...]
python [blahblah] os.system()

Sûrement un problème de droits (avec lesquels tourne le soft). Et sinon, en python, normalement tu as presque tout pour faire du 'systeme' dans os (os.link() ou os.symlink() par exemple)

Et au final, pourquoi pas faire une "db" où les fichiers qui à priori sont partagés par beaucoup (de produits ? arborescences ? versions) seraient stockés quelque part (à part, genre /var/appli/db/, référencés par exemple avec un hash), et la partie 'vivante' serait juste des symlink vers ces 'données' ?