[432] in Athena Bugs
No subject found in mail header
daemon@ATHENA.MIT.EDU (don@ATHENA.MIT.EDU)
Fri Jun 3 21:11:24 1988
From: <don@ATHENA.MIT.EDU>
Date: Fri, 3 Jun 88 21:11:00 EDT
To: bugs@ATHENA.MIT.EDU
i probably discovered the reason that track stimulates an fsck
in update_ws' reboot: track updates several modules which are still
executing; these files' space can't be reclaimed until their
executions are killed by the shutdown, but by that time,
the filesystem is dead, too, so it can't reclaim the space.
ken raeburn suggests the following fix to the update procedure:
"shutdown now" before invoking update_ws, leaving only
init, sh, and 1 or two other processes running.
update_ws begins by unmounting /site, thus exposing the root-fs'
/site/tmp.
update_ws therefore puts hard links to init, sh, etc., in /site/tmp,
after ensuring the /site/tmp exists.
update_ws then proceeds normally.
when update_ws invokes track, all of the executing inodes will
have "back-up" hard links in /site/tmp, so they won't be orphaned.
their space gets freed when the reboot sequence cleans /site/tmp.
-don
