On Wed, May 16, 2007 at 09:29:28AM +0200, u+codalist-p4pg_at_chalmers.se wrote:
> For such and similar reasons I would love, say, having an option of
> "the files right now in the cache shall be there forever".

Not making such files candidates for cache replacement is not that hard.
However if the file is updated on the server it all depends on how the
file was modified.

If the file was updated in place, both the attributes and the data are
invalidated, we first fetch the new attributes, discard the old data,
reserve enough cache space for the new data and finally fetch the new
data. If we disconnect before the new data is fetched we clearly lose.

If the file was moved aside first (foo.orig) and a new file was created
and stored, then again we first fetch attributes followed by the data.
In this case if we got disconnected before the fetch completed the
pinned file is still in the cache, but not with the name the application
expects.

The final update method is to write the new file and then rename it over
the old one. Now the pinning mechanism would have to know that the new
file name is interesting enough to demand fetch. Also we don't actually
see the individual operations that led to the new server state on the
client so really for a client this would look similar to the first case.

We have to know the new file size so we can reserve cache space.

> I think a similar result can be achieved by making a lookaside cache
> of Venus cache. What happens if I hardlink the container files
> into a shadow tree? If Venus does not notice that, it would allow
> a space-efficient preservation of current cache for lookaside.

Venus doesn't unlink container file when they are reused, it simply
truncates the existing ones. So it won't break hardlinks.

Jan