Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: mangler@csvax.caltech.edu (Don Speck)
Newsgroups: comp.sys.sun
Subject: Re: How big will tonight's dump be
Message-ID: <8901292155.AA02589@csvax.caltech.edu>
Date: 8 Feb 89 19:44:11 GMT
Sender: usenet@rice.edu
Organization: California Institute of Technology
Lines: 23
Approved: Sun-Spots@rice.edu
Original-Date: Sun, 29 Jan 89 13:55:03 PST
X-Sun-Spots-Digest: Volume 7, Issue 144, message 2 of 9

Bugs in your script to estimate dump sizes:
    DENS should be *bytes* per inch, not bits.

    "echo yes | /etc/dump" is meaningless, because dump doesn't read stdin;
	it opens /dev/tty.

    killing the first "dump" pid presented by "ps" may leave some
	processes running (depending on the sort order of "ps"; all
	but one "dump" process will be ignoring interrupts, and
	there's a narrow window where ALL of them ignore interrupts)
	or (worse) it may kill processes dumping another disk.

Try this instead:

set `(/etc/dump ${LEVEL}fds - $DENS $SIZE $FILSYS | exit) 2>&1 | grep estimate`

which causes dump to exit with a write error.  $3 gets set to the number
of kilobytes, $7 is the number of tapes.

Either approach seems very crude, and leads me to wonder at the real goal
behind this.  Are you trying to calculate how many filesystems fit on one
tape?  The minimum dump level that will fit on one tape?  Whether you have
enough tapes to proceed?