[26] in Release_7.7_team
Expunging old files
daemon@ATHENA.MIT.EDU (Richard Basch)
Mon Mar 14 19:44:02 1994
Date: Mon, 14 Mar 1994 19:43:33 -0500
To: release-77@MIT.EDU, op@MIT.EDU
Cc: jis@MIT.EDU, kim@MIT.EDU
From: "Richard Basch" <basch@MIT.EDU>
From the release-77 meeting:
f) Expunging old files
The current way expunge works is a resource hog and is causing
operations problems. I've been offered two different implementation
changes, one of which is release dependent, and one of which is not.
They are:
i) Change the default dotfiles to expunge personal files upon login
ii) Make expunge run on each server (Current implementation has
expunge run on a single server over the entire AFS heirarchy.)
User Visibility: High/Medium (i), Low (ii)
Effort: ?
Knowledge: Mark ?
Hits: ?
How does (ii) work?
I am concerned that the ramifications have not fully been considered.
What are the issues that you wish to address?
Is it the fact that the expunging server often hangs after the
traversal over AFS? (This is a client cache manager bug.)
Is it the fact that it takes a long time and doesn't always complete
(multiple servers will aid on this, but it should not be on the fileservers)?
Is it that it sometimes takes a long time because it waits for busy volumes
during the nightly cloning operation?
Is there some confusion with the nightly cloning operation that is being
assumed here (ie. are you actually referring to problems with cloning)?
The only way (ii) can efficiently be run on the fileservers themselves
is if a new process is made that takes note of all the volumes on a
given machine, performs a salvage-like process on each volume, removing
any old expunged data, and is coordinated with the nightly cloning or
some changes done such that deadlocks won't occur. A fileserver cannot
efficiently manage its own data through the filesystem (it is more
inefficient than trying to have another client manage it). What I
outlined here is somewhat dangerous, and will require LOTS of testing,
and is development intensive.
-Richard
