(Illustration by Gaich Muramatsu)
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. JanReceived on 2007-05-16 08:57:47