The VFS's caching with a cache-warmup script is what I use currently.
The reason why you'd want the metadata cached is obviously for the massive performance benefits in searching and general snappy response when browsing through, as fetching the data on-demand has a lot of latency and searches are otherwise just painful... especially via a mount that can not leverage --fast-list
This solution works fine, but it does have 2 non-trivial downsides:
- Does not persist between sessions, so you'll have to warm the cache each time. This may take less than a minute or several minutes depending on how complex the folder structure is.
- The VFS will currently store all this info in RAM. For me this is not much of an issue as my listing fits in about 150MB, but I have seen some huge collections that actually need a GB or more to keep all that data. At point it's no longer trivial... and a database on an SSD is probably more than fast enough anyway in terms of performance. I expect the software can't leverage the full speed of the RAM by a longshot.
Nick has indicated that he has several large changes coming down the road for the VFS - which (according to my understanding) will include persistence in some things like the "upload-list" ect. Using the same framework it's probably quite possible to dump the VFS cache data and re-load it upon restart. We've at least aired that idea before. That would at least solve one problem (having to re-cache each session).