De temps en temps, afin de passer au système nerveux central, j'interviewerai dans diverses grandes entreprises, principalement Saint-Pétersbourg et Moscou, pour le poste de DevOps. J'ai remarqué que de nombreuses entreprises (dans de nombreuses bonnes entreprises, par exemple Yandex) posent deux questions similaires:
- ce qui est inode;
- pour quelles raisons il est possible d'obtenir une erreur d'écriture sur le disque (ou par exemple: pourquoi l'espace disque peut s'épuiser, une essence).
Comme cela arrive souvent, j'étais sûr de bien connaître ce sujet, mais dès que j'ai commencé à expliquer, des lacunes dans les connaissances sont apparues. Afin de systématiser mes connaissances, de combler les lacunes et de ne plus faire honte, j'écris cet article, il peut encore être utile.
Je vais commencer "d'en bas", c'est-à-dire du disque dur (lecteurs flash, SSD et autres choses modernes, nous jetons, par exemple, considérons tout ancien lecteur de 20 ou 80 gigaoctets, car la taille du bloc est de 512 octets).
Le disque dur ne sait pas comment gérer son espace par octet, il est conditionnellement divisé en blocs. La numérotation des blocs commence par 0. (cela s'appelle LBA, détails ici:
en.wikipedia.org/wiki/LBA )
Comme vous pouvez le voir sur la figure, j'ai désigné les blocs LBA comme niveau de disque dur. Au fait, vous pouvez voir la taille de bloc de votre disque:
root@ubuntu:/home/serp
Le niveau supérieur marque la partition, une pour le disque entier (encore une fois, pour plus de simplicité). Le plus souvent, deux types de balisage de partition sont utilisés: msdos et gpt. En conséquence, msdos est un ancien format qui prend en charge des disques jusqu'à 2 To, gpt est un nouveau format qui peut traiter jusqu'à 1 zettaoctet de blocs de 512 octets. Dans notre cas, nous avons une section de type msdos, comme on peut le voir sur la figure, la section dans ce cas commence par le bloc n ° 1, tandis que la section zéro est utilisée pour MBR.
Dans la première section, j'ai créé le système de fichiers ext2, par défaut, la taille du bloc est de 4096 octets, ce qui est également indiqué sur la figure. Vous pouvez voir la taille de bloc du système de fichiers comme ceci:
root@ubuntu:/home/serp
Le paramètre dont nous avons besoin est «Taille du bloc».
Maintenant, le plus intéressant est de savoir comment lire le fichier / home / serp / testfile? Un fichier se compose d'un ou plusieurs blocs du système de fichiers dans lequel ses données sont stockées. Connaître le nom du fichier, comment le trouver? Quels blocs lire?
C'est là que les inodes sont utiles. Le système de fichiers ext2fs possède une «table» qui contient des informations sur tous les inodes. Le nombre d'inodes dans le cas d'ext2fs est défini lors de la création du système de fichiers. Nous regardons les nombres nécessaires dans le paramètre «Inode count» de la sortie tune2fs, c'est-à-dire nous avons 65536 pièces. L'inode contient les informations dont nous avons besoin: une liste de blocs de système de fichiers pour le fichier que vous recherchez. Comment trouver le numéro d'inode pour le fichier spécifié?
La correspondance du nom et du numéro d'inode est contenue dans le répertoire, et le répertoire dans ext2fs est un fichier d'un type spécial, c'est-à-dire possède également son propre numéro d'inode. Afin de briser ce cercle vicieux, un numéro d'inode «fixe» «2» a été attribué au répertoire racine. Nous regardons le contenu de l'inode numéro 2:
root@ubuntu:/
Comme vous pouvez le voir, le répertoire dont nous avons besoin est contenu dans le bloc avec le numéro 579. Dans celui-ci, nous trouverons le numéro de nœud pour le dossier de base, et ainsi de suite le long de la chaîne jusqu'à ce que nous voyions le numéro de nœud pour le fichier demandé dans le répertoire serp. Si tout à coup quelqu'un veut vérifier si le numéro est correct, et s'il y a les bonnes informations là-bas, ce n'est pas difficile. Nous faisons:
root@ubuntu:/
Dans la sortie, vous pouvez lire les noms de fichiers dans le répertoire.
J'en suis donc venu à la question principale: "pour quelles raisons peut-il y avoir une erreur d'écriture"?
Naturellement, cela se produira s'il n'y a pas de blocs libres dans le système de fichiers. Que peut-on faire dans ce cas? Outre l'évident "supprimer quelque chose d'inutile", il faut se rappeler que dans les systèmes de fichiers ext2,3 et 4, il existe une chose telle que "le nombre de blocs réservés". Si vous regardez la liste ci-dessus, nous avons ces blocs "13094". Ce sont des blocs inscriptibles uniquement pour l'utilisateur root. mais si vous avez besoin de résoudre rapidement le problème, comment une solution temporaire peut-elle être mise à la disposition de tout le monde, résultant en un peu d'espace libre:
root@ubuntu:/mnt
C'est-à-dire par défaut, vous ne disposez pas de 5% de l'espace disque disponible pour l'écriture, et compte tenu du volume des disques modernes, il peut s'agir de centaines de gigaoctets.
Quoi d'autre pourrait être? Une situation est possible lorsqu'il y a des blocs libres, mais que les nœuds sont terminés. Cela se produit généralement si vous avez un tas de fichiers dans le système de fichiers qui sont plus petits que la taille de bloc du système de fichiers. Étant donné que 1 inode est dépensé pour 1 fichier ou répertoire, et au total nous les avons (pour ce système de fichiers) 65536 - la situation est plus que réelle. Cela peut être clairement vu à partir de la sortie de la commande df:
serp@ubuntu:~$ df -hi Filesystem Inodes IUsed IFree IUse% Mounted on udev 493K 480 492K 1% /dev tmpfs 493K 425 493K 1% /run /dev/xvda1 512K 240K 273K 47% / none 493K 2 493K 1% /sys/fs/cgroup none 493K 2 493K 1% /run/lock none 493K 1 493K 1% /run/shm none 493K 2 493K 1% /run/user /dev/xvdc1 320K 4,1K 316K 2% /var /dev/xvdb1 64K 195 64K 1% /home /dev/xvdh1 4,0M 3,1M 940K 78% /var/www serp@ubuntu:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 2,0G 4,0K 2,0G 1% /dev tmpfs 395M 620K 394M 1% /run /dev/xvda1 7,8G 2,9G 4,6G 39% / none 4,0K 0 4,0K 0% /sys/fs/cgroup none 5,0M 0 5,0M 0% /run/lock none 2,0G 0 2,0G 0% /run/shm none 100M 0 100M 0% /run/user /dev/xvdc1 4,8G 2,6G 2,0G 57% /var /dev/xvdb1 990M 4,0M 919M 1% /home /dev/xvdh1 63G 35G 25G 59% /var/www
Comme on le voit clairement dans la section / var / www, le nombre de blocs libres dans le système de fichiers et le nombre de nœuds libres varient considérablement.
Au cas où je manquerais d'inode, je ne vous dirais aucun sort, car ils ne le sont pas (sinon, faites le moi savoir). Ainsi, pour les sections dans lesquelles les petits fichiers se multiplient, vous devez sélectionner correctement le système de fichiers. Ainsi, par exemple, dans les inodes btrfs ne peut pas se terminer, car créez dynamiquement de nouveaux si nécessaire.