Re: [9fans] 9p2010

["Steve Simon" <steve@quintile.net>]

> ...integrate the
> caching into a cache file system

this was discussed at one of the iwp9s I believe.

Ok, a thought experiment.

Extend fossil so that you can attach to objects of the form
fs.changes (e.g. main.changes or other.changes). Open a known file
here (e.g. /update) and you will receive a message when any file in
main (or other in the above example) filesystem is modified. The message
should probably be a dirstat structure and a flag indicating weather
the file itself has changed or only the dirstat.

The client could also read from the file /score and would
get a venti score for the watched filesystem every time
a snap is taken.

To allow the system to synchronise after a period of disconnection
the client could write a venti score to /score before opening /update
to indicate that it needs to catch up the changes since this score's
creation.

It would allow cfs to serve up local files with the knowledge that
the remote server contains the same file and so cfs would feel much
mor responsive.

Batched 9p messages would improve the performance further, of course.
You could teach the cache client to use batched 9p from the begining,
and end up with somthing similar to nemo's octopus.

Note, the files I am describing are those served by fossil, so, by
definition they are disk files, and thus they are cacheable.
This is not a solution for virtual files.

I'am sure there are problems with the above, but you get the idea.

-Steve