Linux:¿cómo asigna Linux números de inodo en sistemas de archivos que no se basan en inodos?

Esta es la salida de ls -li comando en el sistema de archivos 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 y 1208 son los números de inodo del directorio y archivo. Sin embargo, el sistema de archivos VFAT no tiene el concepto de inodos.

¿Cómo asigna Linux números de inodo para archivos en un sistema de archivos que no tiene la noción de inodo?

Respuesta aceptada:

tl;dr:para sistemas de archivos virtuales, volátiles o independientes del inodo, los números de inodo generalmente se generan a partir de un contador de 32 bits que se incrementa monótonamente cuando se crea el inodo. El resto del inodo (p. ej., permisos) se crea a partir de los datos equivalentes en el sistema de archivos subyacente, o se reemplaza con valores establecidos en el momento del montaje (p. ej., {uid,gid}= ) si no existe tal concepto.

Para responder a la pregunta del título (es decir, de manera abstracta, cómo Linux asigna números de inodo para un sistema de archivos que no tiene el concepto de inodo), depende del sistema de archivos. Para algunos sistemas de archivos virtuales o sin inodo, el número de inodo se extrae en el momento de la instanciación desde el get_next_ino piscina. Sin embargo, esto tiene una serie de problemas:

1. get_next_ino() usa números de inodo de 32 bits incluso en un kernel de 64 bits, debido al manejo heredado para el espacio de usuario de 32 bits sin _FILE_OFFSET_BITS=64;
2. get_next_ino() es solo un contador de incremento global utilizado por múltiples sistemas de archivos, por lo que el riesgo de desbordamiento aumenta aún más.

Problemas como este son una de las razones por las que moví tmpfs de los inodos respaldados por get_next_ino el año pasado.

Por esta razón, tmpfs en particular es una excepción de la mayoría de los formatos de sistemas de archivos volátiles o "inodeless". Los zócalos, las tuberías, ramfs y similares todavía usan el get_next_ino grupo a partir del 5.11.

En cuanto a su pregunta específica sobre los sistemas de archivos FAT:fs/fat/inode.c es donde se asignan los números de inodo para FAT vilesystems. Si miramos allí, vemos fat_build_inode (fuente):

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;
}

Lo que esto básicamente dice es esto:

1. Obtenga el bloqueo de creación de inodos FAT para este superbloque.
2. Compruebe si el inodo ya existe en esta posición en el superbloque. Si es así, desbloquee y devuelva ese inodo.
3. De lo contrario, cree un nuevo inodo.
4. Obtenga el número de inodo de iunique(sb, MSDOS_ROOT_INO) (más sobre eso en un segundo).
5. Rellene el resto del inodo de las estructuras de datos FAT equivalentes.

inode->i_ino = iunique(sb, MSDOS_ROOT_INO); es donde se establece el número de inodo aquí. iunique (fuente) es una función fs-agnóstica que proporciona números de inodo únicos para un superbloque determinado. Lo hace mediante el uso de una tabla hash basada en superbloque + inodo, con un contador que aumenta monótonamente:

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;
}

En ese sentido, es bastante similar al get_next_ino mencionado anteriormente. :solo por superbloque en lugar de ser global (como para tuberías, enchufes o similares), y con alguna protección rudimentaria basada en tablas hash contra colisiones. Incluso hereda get_next_ino El comportamiento del inodo de 32 bits utiliza números de inodo de 32 bits como método para tratar de evitar EOVERFLOW en aplicaciones heredadas, por lo que es probable que haya más sistemas de archivos que necesiten correcciones de inodo de 64 bits (como mi mencionado inode64 implementación para tmpfs) en el futuro.

Relacionado:Linux:¿cómo agregar a un archivo como sudo?

Así que para resumir:

1. La mayoría de los sistemas de archivos virtuales o sin inodo utilizan un contador que se incrementa monótonamente para el número de inodo.
2. Ese contador no es estable ni siquiera para sistemas de archivos inodeless en disco*. Puede cambiar sin otros cambios en el sistema de archivos al volver a montar.
3. La mayoría de los sistemas de archivos en este estado (excepto tmpfs con inode64 ) siguen usando contadores de 32 bits, por lo que con un uso intensivo es muy posible que el contador se desborde y termine con inodos duplicados.

* …aunque, para ser justos, por contrato esto es cierto incluso para los sistemas de archivos que hacen tener un concepto de inodo cuando i_generation cambios:es menos probable que suceda en la práctica, ya que a menudo el número de inodo está relacionado con su posición física o algo similar.