Ceci est la sortie de ls -li commande sur le système de fichiers VFAT.
% ls -li
合計 736
1207 drwxr-xr-x 3 root root 16384 3月 10 10:42 efi
1208 -rwxr-xr-x 1 root root 721720 3月 22 14:15 kernel.bin
1207 et 1208 sont les numéros d'inode du répertoire et du fichier. Cependant, le système de fichiers VFAT n'a pas le concept d'inodes.
Comment Linux attribue-t-il des numéros d'inode aux fichiers d'un système de fichiers qui n'a pas la notion d'inode ?
Réponse acceptée :
tl;dr :pour les systèmes de fichiers virtuels, volatils ou indépendants des inodes, les numéros d'inode sont généralement générés à partir d'un compteur 32 bits à incrémentation monotone lors de la création de l'inode. Le reste de l'inode (par exemple, les autorisations) est construit à partir des données équivalentes dans le système de fichiers sous-jacent, ou est remplacé par des valeurs définies au moment du montage (par exemple, {uid,gid}= ) si un tel concept n'existe pas.
Pour répondre à la question dans le titre (c'est-à-dire abstraitement, comment Linux alloue les numéros d'inode pour un système de fichiers qui n'a pas de concept d'inode), cela dépend du système de fichiers. Pour certains systèmes de fichiers virtuels ou sans inode, le numéro d'inode est tiré au moment de l'instanciation à partir de get_next_ino bassin. Cela pose cependant un certain nombre de problèmes :
get_next_ino()utilise des numéros d'inode 32 bits même sur un noyau 64 bits, en raison de la gestion héritée de l'espace utilisateur 32 bits sans_FILE_OFFSET_BITS=64;get_next_ino()n'est qu'un compteur à incrémentation globale utilisé par plusieurs systèmes de fichiers, ce qui augmente encore le risque de débordement.
Des problèmes comme celui-ci sont l'une des raisons pour lesquelles j'ai déplacé tmpfs des inodes sauvegardés par get_next_ino l'année dernière.
Pour cette raison, tmpfs en particulier est une exception à la plupart des formats de système de fichiers volatils ou "inodeless". Les sockets, pipes, ramfs et autres utilisent toujours le get_next_ino piscine à partir du 5.11.
En ce qui concerne votre question spécifique sur les systèmes de fichiers FAT :fs/fat/inode.c est l'endroit où les numéros d'inode sont alloués pour les vilesystems FAT. Si nous regardons là-dedans, nous voyons fat_build_inode (source):
struct inode *fat_build_inode(struct super_block *sb,
struct msdos_dir_entry *de, loff_t i_pos)
{
struct inode *inode;
int err;
fat_lock_build_inode(MSDOS_SB(sb));
inode = fat_iget(sb, i_pos);
if (inode)
goto out;
inode = new_inode(sb);
if (!inode) {
inode = ERR_PTR(-ENOMEM);
goto out;
}
inode->i_ino = iunique(sb, MSDOS_ROOT_INO);
inode_set_iversion(inode, 1);
err = fat_fill_inode(inode, de);
if (err) {
iput(inode);
inode = ERR_PTR(err);
goto out;
}
fat_attach(inode, i_pos);
insert_inode_hash(inode);
out:
fat_unlock_build_inode(MSDOS_SB(sb));
return inode;
}
Voici ce que cela dit :
- Prenez le verrou de création d'inode FAT pour ce superbloc.
- Vérifiez si l'inode existe déjà à cette position dans le superbloc. Si c'est le cas, déverrouillez et renvoyez cet inode.
- Sinon, créez un nouvel inode.
- Obtenir le numéro d'inode de
iunique(sb, MSDOS_ROOT_INO)(plus à ce sujet dans une seconde). - Remplissez le reste de l'inode à partir des structures de données FAT équivalentes.
inode->i_ino = iunique(sb, MSDOS_ROOT_INO); est l'endroit où le numéro d'inode est défini ici. iunique (source) est une fonction indépendante de fs qui fournit des numéros d'inode uniques pour un superbloc donné. Pour ce faire, il utilise une table de hachage basée sur superbloc + inode, avec un compteur croissant de manière monotone :
ino_t iunique(struct super_block *sb, ino_t max_reserved)
{
static DEFINE_SPINLOCK(iunique_lock);
static unsigned int counter;
ino_t res;
rcu_read_lock();
spin_lock(&iunique_lock);
do {
if (counter <= max_reserved)
counter = max_reserved + 1;
res = counter++;
} while (!test_inode_iunique(sb, res)); /* nb: this checks the hash table */
spin_unlock(&iunique_lock);
rcu_read_unlock();
return res;
}
À cet égard, il est assez similaire au get_next_ino mentionné précédemment :juste par superbloc au lieu d'être global (comme pour les tubes, les sockets, etc.), et avec une protection rudimentaire basée sur la table de hachage contre les collisions. Il hérite même de get_next_ino le comportement de utilise des numéros d'inode 32 bits comme méthode pour essayer d'éviter EOVERFLOW sur les applications héritées, il y aura donc probablement plus de systèmes de fichiers qui auront besoin de correctifs d'inode 64 bits (comme mon inode64 mentionné ci-dessus implémentation pour tmpfs) à l'avenir.
Donc pour résumer :
- La plupart des systèmes de fichiers virtuels ou sans inode utilisent un compteur à incrémentation monotone pour le numéro d'inode.
- Ce compteur n'est pas stable même pour les systèmes de fichiers inodeless sur disque*. Il peut changer sans autres modifications du système de fichiers lors du remontage.
- La plupart des systèmes de fichiers dans cet état (à l'exception de tmpfs avec
inode64) utilisent toujours des compteurs 32 bits. Par conséquent, en cas d'utilisation intensive, il est tout à fait possible que le compteur déborde et que vous vous retrouviez avec des inodes en double.
* … bien que, pour être juste, par contrat, cela est vrai même pour les systèmes de fichiers qui font avoir un concept d'inode quand i_generation changements - cela est simplement moins susceptible de se produire dans la pratique car souvent le numéro d'inode est lié à sa position physique, ou similaire.