From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3B042432.691F18B8@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20010512130225.4B64F199E1@mail.cse.psu.edu>, <9dshfp$3cu$1@cantaloupe.srv.cs.cmu.edu> Subject: Re: [9fans] Persistent cache for cfs Date: Fri, 18 May 2001 08:35:41 +0000 Topicbox-Message-UUID: a1261d12-eac9-11e9-9e20-41e7f4b1d025 Matthew Weigel wrote: > ... for special cases such as files that were edited both > locally and on the fs while the client was disconnected could be > presented as file.kfs- and > file.fs-, so that the user could see both and decide > what to do. More thought is needed before inventing warts like this. This is just a concurrent-update issue, widely studied already. It may be that nothing special needs to be done about such occurrences; the last writer wins. It seems to me that the only thing distinguishing a stash from a normal filesystem from the user perspective is that files have a new two-valued attribute, "temporary" or "permanent", which is honored by the caching scheme. Behind the scenes there must also be a mechanism for specifying how to construct the stash filesystem, but that can be as simple as an init rc script containing some "copy permanent files into place" instructions. You probably want additional specification capability for what the stash needs to do when a nonexistent file is accessed and also when the cache is full. Also what to do upon termination, again possibly an rc script that copies out updated files.