Ich plane, ein FUSE-Dateisystem mit einer Low-Level-API zu implementieren und versuche derzeit, fuse_entry_param structure zu verstehen.
Ich frage mich, was unsigned long fuse_entry_param::generation eigentlich bedeutet. Dokumentation sagt , dass das Paar ino / generation für die Lebenszeit des Dateisystems eindeutig sein sollte, aber nicht geht in irgendwelche Details.
Was ist die Semantik von Inode-Generationen und wie werden sie verwendet?
Zum Beispiel kann ich generation als zusätzliche Bits von ino (wie eine Art Namespace) betrachten und sie frei verwenden, um beliebige lebenslänglich eindeutige 128-Bit-Werte ( 2*sizeof(unsigned long) auf x86_64) zuzuordnen Inodes? Oder Generationen sollen nur sequentiell inkrementiert werden? Was passiert, wenn die Inode-Nummern kollidieren, aber ihre Generierungsnummern abweichen?
Das Feld 'Generation' ist wichtig, wenn Ihr Inode-Nummerngenerator zu einem anderen Zeitpunkt für dasselbe Objekt unterschiedliche Inode-Nummern erzeugen kann. Dies ist ungewöhnlich für Dateisysteme auf der Festplatte, kann aber bei Netzwerk-Dateisystemen auftreten (wie NFS, siehe 1 ).
Es wird in 1 erwähnt, dass a Der Server kann nach einem Neustart einen anderen Satz von (Sicherung) Inode-Nummern / (NFS) -Datei-Handles verwenden. Wenn das passiert, ist es möglich, dass die neuen Inode-Nummern Objekte anders zuordnen als die Inode-Nummern, die vor dem Neustart des Servers ausgegeben wurden. Ein Client könnte eine andere Generationsnummer für den Satz von Inode vor Neustart und für den Satz von Inodes nach Neustart verwenden, um klar zu machen, welcher Inode gemeint ist.
Wenn Ihr Dateisystem über ein statisches Erzeugungsschema für Inodes verfügt (wobei eine Inode-Nummer immer auf dasselbe Objekt verweist), ist es nicht erforderlich, die Generierungsnummer zu verwenden und die Inode-Nummer zu erweitern.
Tags und Links linux-kernel filesystems inode fuse vfs