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.
> >
>