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