Pourquoi les fichiers de périphériques spéciaux ont-ils des inodes?

11

Les fichiers de périphérique ne sont pas des fichiers en soi. Il s'agit d'une interface d'E / S pour utiliser les périphériques dans les systèmes d'exploitation de type Unix. Ils n'utilisent pas d'espace sur le disque, cependant, ils utilisent toujours un inode comme indiqué par la statcommande:

$ stat /dev/sda
      File: /dev/sda
      Size: 0               Blocks: 0          IO Block: 4096   block special file
Device: 6h/6d   Inode: 14628       Links: 1     Device type: 8,0

Les fichiers de périphérique utilisent-ils des inodes physiques dans le système de fichiers et pourquoi en ont-ils besoin?

— direprobs
source

2

L'inode et les données sont le fichier. Sans inode, vous n'avez pas de fichier. (Les fichiers de l'appareil n'ont pas de données cependant)

— user253751

16

La réponse courte est que cela ne fonctionne que si vous avez un support de système de fichiers physique /dev(et si vous utilisez une distribution Linux moderne, vous ne l'avez probablement pas).

La réponse longue suit:

Tout cela revient à la philosophie UNIX originale selon laquelle tout est un fichier. Cette philosophie fait partie de ce qui a rendu UNIX si polyvalent, car vous pouvez interagir directement avec les périphériques de l'espace utilisateur sans avoir besoin de code spécial dans votre application pour parler directement au matériel physique.

À l'origine, /devc'était juste un autre répertoire avec un nom bien connu où vous placez les fichiers de votre appareil. Certains systèmes UNIX adoptent toujours cette approche (je crois qu'OpenBSD le fait toujours), et vous pouvez généralement dire si un système est comme ça car il aura beaucoup de fichiers de périphérique pour les périphériques que le système n'a pas réellement (par exemple, des fichiers pour chaque partition possible sur chaque disque possible). Cela permet d'économiser de l'espace en mémoire et du temps au démarrage au prix d'utiliser un peu plus d'espace disque, ce qui était un bon compromis pour les premiers systèmes car ils étaient généralement très limités en mémoire et pas très rapides. Ceci est généralement appelé «statique» /dev.

Sur les systèmes Linux modernes (et je crois aussi FreeBSD et peut-être les versions récentes de Solaris), /devest un système de fichiers en mémoire temporaire peuplé par le noyau (ou udev si vous utilisez Systemd, car ils ne font pas confiance au noyau pour faire presque n'importe quoi) . Cela permet d'économiser de l'espace disque au prix d'une certaine mémoire (généralement moins de quelques Mo) et une très petite surcharge de traitement. Il présente également un certain nombre d'autres avantages, l'un des plus importants étant qu'il est plus facile de détecter le matériel branché à chaud. C'est ce qu'on appelle généralement une dynamique /dev.

Dans les deux cas cependant, les nœuds de périphérique sont accessibles via la couche VFS normale, ce qui signifie par définition qu'ils doivent avoir un inode (même s'il s'agit d'un nœud virtuel qui existe juste pour que des trucs comme stat()fonctionnent comme il est censé le faire. D'un point de vue pratique, cela n'a aucun impact sur les systèmes qui utilisent une dynamique /devcar ils stockent simplement les inodes en mémoire ou les génèrent selon les besoins, et un impact proche de zéro où /devest statique car les inodes occupent un espace presque nul sur le disque et la plupart des systèmes de fichiers n'ont aucune limite supérieure sur eux ou la fourniture de façon plus que quiconque est susceptible d'avoir besoin.

— Austin Hemmelgarn
source

3

Lève prudemment la main. J'ai été sur un projet qui avait un serveur à court d'inodes. C'était finalement la crise dont notre équipe avait besoin pour convaincre la direction d'investir dans le remplacement de ce système backend, qui avait été conçu (mal, comme vous pouvez l'imaginer!) Avant qu'aucun d'entre nous n'y soit arrivé.

— KRyan

@KRyan Cela peut arriver, mais ces jours-ci, c'est rare, sauf si l'administrateur a explicitement réduit le nombre lors de la création du système de fichiers. De nombreux systèmes de fichiers modernes (au moins NTFS, BTRFS et ZFS, je pense que XFS pourrait aussi) allouent réellement les inodes de manière dynamique, donc sur de nombreux systèmes plus récents, il est en fait impossible de s'épuiser.

— Austin Hemmelgarn

@KRyan Moi aussi, j'ai eu ce problème. Et c'était en fait un système bien conçu, s'il était un peu daté et amené à l'extream (chaque transaction nécessitait un journal indépendant, qui était conservé sur le disque, finalement il était juste rempli de minuscules petits inodes)

— coteyr

1

Od et docker est un peu célèbre pour avoir causé exactement ce problème d'inode.

— coteyr

@AustinHemmelgarn La famille ext est assez tristement célèbre pour avoir un nombre statique d'inodes (et par la suite s'épuiser). C'est aussi, incidemment, le système de fichiers Linux le plus utilisé par probablement une énorme marge (scénarios qui stockent d'énormes quantités de données sur XFS, avec ZFS et BTRFS étant relativement nouveau), et la valeur par défaut pour la plupart des distributions. Bien sûr, dans un système moderne, les inodes max par défaut sont de plusieurs ordres de grandeur supérieurs au nombre de fichiers de périphérique que vous aurez jamais.

— Bob

15

Les fichiers de périphérique ont également des autorisations et celles-ci sont stockées dans un inode.

— Hauke Laging
source

Excellent point que j'ai oublié de mentionner.

— Austin Hemmelgarn

5

Pas seulement les autorisations, mais aussi le type de fichier et d'autres métadonnées. Classiquement, le répertoire lui-même ne contient que le nom et le numéro d'inode - rien n'indique que le fichier est un périphérique tant que vous n'avez pas lu l'inode.

— Gilles 'SO- arrête d'être méchant'

12

Les répertoires sont simplement un mappage des noms de fichiers aux inodes, donc tout sur la chose à laquelle le nom fait référence (un fichier, un lien symbolique, un périphérique, un FIFO, une socket) doit être dans l'inode, il n'y a nulle part ailleurs où le mettre.

Les informations sur l'appareil sont stockées dans l'inode. Les numéros de périphérique majeur et mineur sont là, tout comme les autorisations, les horodatages, etc. Le champ type qui indique qu'il s'agit d'un périphérique de bloc ou de caractère plutôt qu'un fichier normal y est stocké.

L'inode pour les appareils n'utilise tout simplement pas les champs qui contiennent la carte de bloc du fichier.

— Barmar
source

0

Sans inode, vous n'auriez que le nom de fichier pour contenir toutes les informations sur l'appareil en question. Cela signifie /dev/sdaqu'il n'est pas question de noms de périphériques «agréables» comme : vous auriez besoin d'un nom qui pourrait être lié à un pilote particulier, comme /dev/ohci/sda.

Plus important encore, tous les outils qui reposent sur des inodes (comme stat, lset ainsi de suite) devraient être modifiés pour traiter les chemins sous /devd'une manière spéciale. Ce serait une quantité de travail prohibitive sans aucun avantage apparent par rapport à l'état actuel des choses.

— Dmitry Grigoryev
source