Backup of a live filesystem revisited

[System Mangler]

In article <5108 at pur-ee.UUCP>, davy at pur-ee.UUCP (Dave Curry) writes:
>	1. Nice yourself down as far as you can.  Like -20.

    A couple weeks ago a friend was converting a VMS BACKUP tape for me,
and as we stood around while the TU80 slowly turned, I wisecracked about
the TU80 on the nearby 4.3 BSD machine, which was turning just as slowly.
He retorted that he had reverse-nice'd /etc/dump to -20, users be damned.
Later, I found that the reverse-nice (mean?) was what made dump run so
slowly.

4.3 BSD dump uses several processes, to overlap disk and tape I/O.
Since it is I/O-bound, `usrpri' stays pretty close to PUSER+2*nice.
If nice is more negative than -6, this will be a better priority
than the flock wakeup priority, so the scheduler favors the current
process instead of waking up the next tape writer.  If nice is more
negative than -14, the current process gets priority over disk I/O
completions too.

I think the I/O wakeup priorities are much too close to PUSER; PZERO
ought to be changed to about 10.

>	2. Modify dump (most of the mods are in dumptraverse.c) to
>	   skip any inode whose mtime or ctime is greater than
>	   spcl.c_date (time of the dump).

This means that a full dump of the root filesystem will be missing
/dev/console and /dev/rmt8.  Not my idea of a useful backup...

The modifications affect only pass IV.	But that wasn't where dump
was weak.  An rm -r during passes I/II/III of stock 4.2 BSD dump
will make restore dump core.  4.3 BSD /etc/dump skips deleted files
and directories, allowing restore to get *much* further before
dumping core, and it seems to have no problem with deletions
during pass IV.

The only thing I have to add to the 4.3 BSD sanity checks would
be a warning message in dirdump(), since a deleted directory is
still quite likely to make the dump useless.

Don Speck   speck at vlsi.caltech.edu  {seismo,rutgers,ames}!cit-vax!speck