In meiner Vorstellung sieht das so aus:
Das VFS sollte nur zweckgebunden Sachen laden. Wenn jemand alle Dateien in einem Verzeichnis auflistet, sollte das VFS nicht einfach so auch die Unterverzeichnisse laden, sondern erst, wenn das Programm danach fragt. Und die Schnittstellen zum User Space sehen in der Regel so aus, dass dem VFS die Option bleibt, beim rekursiven Auflisten von Verzeichnissen nicht genutzte Objekte wieder freizugeben. Das VFS funktioniert da ja nur als eine Art Cache. Die tatsächlichen Dateiinformationen können immer vom Dateisystemtreiber rekonstruiert werden. Die paar VFS-Objekte, die keine Repräsentation in einem anderen Treiber haben (Mountpoints evtl.), sollten so wenige sein, dass sie nicht ins Gewicht fallen.
Unter Windows gibt es beispielsweise FindFirstFile/FindNextFile zum Auflisten von Dateien im Verzeichnis. Mit FindFirstFile wird nur ein Handle erzeugt, und zum User Space hin nur eine Datei/Verzeichnis präsentiert. Durch wiederholtes Aufrufen von FindNextFile wird über die weiteren Dateien/Verzeichnisse iteriert. Dem VFS steht es offen nachdem FindNextFile aufgerufen wurde, die Informationen über die Datei, die davor betrachtet wurde, schon wieder freizugeben, falls der Platz knapp wird.
Das heißt, wenn du deine API ähnlich wie FindNextFile oder opendir (POSIX) strukturierst, wirst du nie das Problem haben, dass du zu viele Informationen verwalten musst, weil du immer die Option hast, die wieder freizugeben.