(Illustration by Gaich Muramatsu)
We regularly assign a class project that modifies Venus to perform prefectching. Here is the most recent version of the project. -- Satya On Saturday 24 November 2012 19:46:31 Dhaivat Pandya wrote: > The reason I kind of combined prefetching and caching was more because I > meant "prefetching or caching". > > So, does Venus attempt to "predict" subsequent file open()s and prefetch > files? As far as I understand your email, the answer is no. > > I am attempting to work on a system that tries to predict filesystem events > based on prior experience and then use that the prefetch. As you mentioned, > directory wide prefetching is impractical a lot of the time, so, something > that was more clever might be helpful. Any feedback on this would be great. > > Thanks for the reply - it was very helpful. > > > On Sat, Nov 24, 2012 at 6:34 PM, Greg Troxel <gdt_at_ir.bbn.com> wrote: > > > > > Dhaivat Pandya <dhaivatpandya_at_gmail.com> writes: > > > > > Does Venus attempt to do any sort of predictive prefetching/caching aside > > > from the user specified HDB entries? > > > > Prefetching and caching are quite different. Venus will cache files > > that it reads, either due to VFS requests or hoarding. I am unaware of > > any prefetching. For example, one could have venus read (into the > > cache) files in a directory if the directory is read. That doesn't > > sound like a good plan, because a directory of large files is something > > that might be listed but not entirely traversed. > > > > Were I to investigate prefetching, I'd add: > > > > 1) stat files in a directory when the directory is read > > > > 2) if any of those files are directories, fault them into the cache > > (but don't 1 until there's a real VFS call) > > > > Before doing this, I'd want to have some sort of priority queueing by > > request uid or reason, so that prefetches don't compete with real > > requests. And probably analyze some traces, although user behavior > > adapts to FS behavior, so the actual question of what's best is far > > trickier than it might at first seem. > > >