Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: Quelling Filesystem Activity
Message-ID: <5321@umcp-cs.UUCP>
Date: Tue, 30-Apr-85 15:32:27 EDT
Article-I.D.: umcp-cs.5321
Posted: Tue Apr 30 15:32:27 1985
Date-Received: Thu, 2-May-85 04:49:43 EDT
References: <134@kontron.UUCP> <10291@brl-tgr.ARPA>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 17

Doug Gwyn's suggestion ("wall" followed by umount 'til it succeeds) is
fine IF you can count on everyone using that file system to clean up
when you want them---not likely here, and (I daresay) most places.
(Not that we have evil users:  there's a good chance the processes
using the disk aren't under human supervision.)

However, in the meantime, here's a crazy idea:  a "suspendfs" system
call, which locks all the inodes in that file system (have to be sure
you don't run it while cd'ed there!), forcing any programs using it to
be suspended if they attempt to write it (or read it; well, maybe we
can work around that one...).  Then you can update() (which just writes
buffer cache, so doesn't run into those locks), dump, and "resumefs",
with all of those processes happily ignorant of the file system save.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland