gm@kontron.UUCP (Greg McGary) (04/27/85)
Here's the problem: I want to dump a filesystem while running
multi-user. I specifically *do*not* want to dump an active filesystem,
so I must be able to unmount it while it is potentially active.
Here's what I need: I want a utility that will aid me in quelling
filesystem activity so that I can unmount it. The approach is to
examine /dev/kmem to identify pids of processes that have open files
in that filesystem, kill them, and unmount the fs.
Does anyone have such a utility that they are willing to post, or
another approach to taking clean dumps of a filesystem without having
to go down to single-user? If no one has one, I'll write it myself and
post it to net.sources.
Thanx,
Greg McGary
{unisoft,felix,scgvaxd,trwrb}!pertec!kontron!gmguy@sun.uucp (Guy Harris) (04/30/85)
> Here's what I need: I want a utility that will aid me in quelling > filesystem activity so that I can unmount it. The approach is to > examine /dev/kmem to identify pids of processes that have open files > in that filesystem, kill them, and unmount the fs. > > Does anyone have such a utility... If you have access to System V source, try the "fuser" utility. It "Lists the process IDs of the processes using the files specified as arguments. For block special devices, all processes using any file on that device are listed." The "-k" flag sends SIGKILL to those processes. It's not too hard to modify to work on systems other than System V. Guy Harris
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (04/30/85)
> Here's the problem: I want to dump a filesystem while running > multi-user. I specifically *do*not* want to dump an active filesystem, > so I must be able to unmount it while it is potentially active. > > Here's what I need: I want a utility that will aid me in quelling > filesystem activity so that I can unmount it. The approach is to > examine /dev/kmem to identify pids of processes that have open files > in that filesystem, kill them, and unmount the fs. Killing an innocent process that is doing possibly useful work just so you can unmount the filesystem is NOT NICE. How about: wall 'Please get away from filesystem X so I can back it up.' until umount X; do sleep 15; done echo 'Ok, back X up.'
chris@umcp-cs.UUCP (Chris Torek) (04/30/85)
I was considering fiddling with the umount() system call to add a force
flag, or creating a new system call, which would take away access to a
file system, so that it could be unmounted without taking the machine
down, but never went through with it. It could be done by taking away
both FREAD and FWRITE permission and syncing and marking in-core inodes
as trash, or something, or (and I kinda like this idea) by actually
switching fp->f_data pointers over to a /dev/null inode and closing the
real files. It was starting to look ugly, so I never finished it. Oh
well....
--
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@marylandchris@umcp-cs.UUCP (Chris Torek) (04/30/85)
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@marylandjim@ISM780B.UUCP (05/03/85)
>Here's what I need: I want a utility that will aid me in quelling >filesystem activity so that I can unmount it. The approach is to >examine /dev/kmem to identify pids of processes that have open files >in that filesystem, kill them, and unmount the fs. From SysV FUSER(1M): Fuser lists the process IDs of the processes using the files specified as arguments. For block special devices, all processes using any file on that device are listed. ... -- Jim Balter, INTERACTIVE Systems (ima!jim)
smk@axiom.UUCP (Steven M. Kramer) (05/05/85)
umount will fail for other reasons besides just open files on the
file system in question. If anyone has a current dir in the file
system, it will also fail. And, of course, if another file system
is mounted on a directory there, umount fails then.
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)jbn@wdl1.UUCP (05/10/85)
Vagrant thought: with the fast file system in 4.2BSD, how fast could a dumper that dumped file by file be made to run? If tape I/O were overlapped with file I/O (using one process to read the files and another to write the tape, with a pipe between) and huge reads were performed, how much worse would this be than reading raw file systems? Maybe we can get rid of these around-the-file-system dumpers. John Nagle