From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Matthew Weigel Message-ID: <9e3umm$nm6$1@cantaloupe.srv.cs.cmu.edu> References: <20010512130225.4B64F199E1@mail.cse.psu.edu>, <9dshfp$3cu$1@cantaloupe.srv.cs.cmu.edu>, <3B042432.691F18B8@null.net> Subject: Re: [9fans] Persistent cache for cfs Date: Mon, 21 May 2001 08:39:30 +0000 Topicbox-Message-UUID: a43f8f7e-eac9-11e9-9e20-41e7f4b1d025 Douglas A. Gwyn wrote: >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. That might be fine, sure. I was more concerned with files accessed by multiple people; I don't entirely like the idea of "shouldn't be a problem, let's hope it isn't." >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. What nonexistant files? :) The way I was seeing it, if you're not connected to an fs, then the stashfs would only show files that existed in the stash. When the stash is full, it would be a reasonable first pass to delete the oldest files until sufficient space frees up; beyond that, looking at other people's work in the area seems prudent. Keeping a list of dirty files in the kfs seems reasonable - upon termination, a script could remount the kfs volume and finish any writes. This may be going through too many gymnastic routines to avoid writing a different filesystem on disk, but it seems like this would be an excellent example of where stacking single-purpose, user-level filesystems can give useful filesystem behavior. -- Matthew Weigel Research Systems Programmer mcweigel+@cs.cmu.edu