Linux – Wie weist Linux Inodes-Nummern auf Dateisystemen zu, die nicht auf Inodes basieren?

Dies ist die Ausgabe von ls -li Befehl auf dem VFAT-Dateisystem.

% 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 und 1208 sind die Inode-Nummern des Verzeichnisses und der Datei. Das VFAT-Dateisystem kennt jedoch kein Inodes-Konzept.

Wie weist Linux Inode-Nummern für Dateien auf einem Dateisystem zu, das den Inode-Begriff nicht hat?

Akzeptierte Antwort:

tl;dr:Für virtuelle, flüchtige oder Inode-agnostische Dateisysteme werden Inode-Nummern normalerweise aus einem monoton inkrementierenden 32-Bit-Zähler generiert, wenn der Inode erstellt wird. Der Rest des Inodes (z. B. Berechtigungen) wird aus den entsprechenden Daten im zugrunde liegenden Dateisystem erstellt oder durch Werte ersetzt, die zum Zeitpunkt des Mountens festgelegt werden (z. B. {uid,gid}=). ), falls kein solches Konzept existiert.

Um die Frage im Titel zu beantworten (dh abstrakt, wie Linux Inode-Nummern für ein Dateisystem zuweist, das kein Inode-Konzept hat), hängt es vom Dateisystem ab. Bei einigen virtuellen oder inodelosen Dateisystemen wird die Inode-Nummer zum Zeitpunkt der Instanziierung aus get_next_ino gezogen Schwimmbad. Dies hat jedoch eine Reihe von Problemen:

1. get_next_ino() verwendet 32-Bit-Inode-Nummern sogar auf einem 64-Bit-Kernel, aufgrund der Legacy-Handhabung für 32-Bit-Userland ohne _FILE_OFFSET_BITS=64;
2. get_next_ino() ist nur ein global inkrementierender Zähler, der von mehreren Dateisystemen verwendet wird, sodass das Risiko eines Überlaufs noch weiter erhöht wird.

Probleme wie diese sind einer der Gründe, warum ich letztes Jahr tmpfs von get_next_ino-unterstützten Inodes wegbewegt habe.

Aus diesem Grund ist insbesondere tmpfs eine Ausnahme von den meisten flüchtigen oder „inodelosen“ Dateisystemformaten. Sockets, Pipes, Ramfs und dergleichen verwenden immer noch get_next_ino Pool ab 5.11.

Zu Ihrer speziellen Frage zu FAT-Dateisystemen:fs/fat/inode.c Hier werden Inode-Nummern für FAT-Vilesysteme zugewiesen. Wenn wir dort hineinschauen, sehen wir fat_build_inode (Quelle):

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

Was dies im Wesentlichen sagt, ist Folgendes:

1. Nehmen Sie die FAT-Inode-Erstellungssperre für diesen Superblock.
2. Überprüfen Sie, ob der Inode bereits an dieser Position im Superblock existiert. Wenn ja, entsperren Sie diesen Inode und geben Sie ihn zurück.
3. Andernfalls erstellen Sie einen neuen Inode.
4. Holen Sie sich die Inode-Nummer von iunique(sb, MSDOS_ROOT_INO) (mehr dazu gleich).
5. Füllen Sie den Rest des Inodes aus den entsprechenden FAT-Datenstrukturen.

inode->i_ino = iunique(sb, MSDOS_ROOT_INO); Hier wird die Inode-Nummer eingestellt. iunique (Quelle) ist eine fs-agnostische Funktion, die eindeutige Inode-Nummern für einen bestimmten Superblock bereitstellt. Dies geschieht durch die Verwendung einer Superblock + Inode-basierten Hash-Tabelle mit einem monoton steigenden Zähler:

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

In dieser Hinsicht ist es dem zuvor erwähnten get_next_ino ziemlich ähnlich :Nur pro Superblock, anstatt global zu sein (wie für Pipes, Sockets oder ähnliches) und mit einem rudimentären, auf Hash-Tabellen basierenden Schutz gegen Kollisionen. Es erbt sogar get_next_ino ’s Verhalten bei der Verwendung von 32-Bit-Inode-Nummern als Methode, um EOVERFLOW bei Legacy-Anwendungen zu vermeiden, so dass es wahrscheinlich mehr Dateisysteme geben wird, die 64-Bit-Inode-Korrekturen benötigen (wie mein oben erwähntes inode64 Implementierung für tmpfs) in der Zukunft.

Verwandte:Linux – Wie man als sudo an eine Datei anhängt?

Zusammenfassend also:

1. Die meisten virtuellen oder inodelosen Dateisysteme verwenden einen monoton inkrementierenden Zähler für die Inode-Nummer.
2. Dieser Zähler ist nicht einmal für Dateisysteme ohne Inode auf der Festplatte stabil*. Es kann sich ohne weitere Änderungen am Dateisystem beim erneuten Mounten ändern.
3. Die meisten Dateisysteme in diesem Zustand (außer tmpfs mit inode64 ) verwenden immer noch 32-Bit-Zähler, daher ist es bei starker Nutzung durchaus möglich, dass der Zähler überläuft und Sie am Ende doppelte Inodes erhalten.

* … obwohl dies, um fair zu sein, per Vertrag sogar für Dateisysteme gilt, die tun ein Inode-Konzept haben, wenn i_generation Änderungen – es ist nur weniger wahrscheinlich, dass dies in der Praxis passiert, da die Inode-Nummer oft mit ihrer physischen Position oder ähnlichem zusammenhängt.