Is dump dumb?

[Don Speck]

In article <170 at cui.UUCP>, petitp at cui.UUCP (PETITPIERRE Dominique) asks:
>	- Why doesn't 'restore -t' give you the name of the file system stored
>	on the tape?

UKC has modified dump/restore to record and display this information,
and they gave the changes to Berkeley.	Perhaps it is in 4.3T.

>	- Is it true that restored files will have their modification time
>	always set to the time of the restore command?

If you abort when it asks 'set owner/mode for "."?', the directory
modification times won't be preserved.

>	- Why isn't it possible to specify the size of the tape in (mega) bytes

All tape accounting is in tenths of an inch.  There's an unused function
in dumpoptr.c which hints that it may have once been in units of blocks
(which is more sensible).  There's four options (five on Suns) that go
into determining one number and it's still not accurate (no "gap" option).

>	In fact why doesn't dump use all the space available on the tape
>	without being told how much on the command line?

The only Unix indication that the tape is full is a write error.  One
doesn't know whether the last block or two will be readable, and some
(cartridge) tape drives can't backspace, so dump would need to replicate
the last few blocks onto the next tape, and indicate this in the TS_TAPE
header via spcl.c_tapea.  Restore would have to be modified to discard
appropriately.

In a multi-process dump, where the i-list traversing process may be
600K ahead of actual tape writing, being able to "back up" like this
requires keeping an inode/blocknumber pair for each tape block, and
modifying the indirect-block traversal algorithm so that it can be
restarted from an arbitrary blocknumber (i.e. not be recursive).
This is a radical change.

>	- Why can't dump work on active file systems?

If directory entries are removed/renamed before Pass IV, or a large
file is truncated while traversing its indirect blocks, the dump will
be inconsistent.  4.3 BSD dump detects some cases and skips, but it
is still susceptible.

Tar and cpio have the SAME PROBLEM.  I am aghast at how many people
think otherwise.

Any other activity is allowed.	Linking, creating, and appending files
should be OK because inodes and directory entries are written atomically.
You should even be able to dump to a (new) file in the same filesystem,
since it won't exist until after the mapping passes are finished (try
that with cpio!).  Just don't rename, remove, or truncate anything.

In article <23063 at labrea.Stanford.EDU> karish at denali.stanford.edu (Chuck Karish) writes:
>If you run it on an active file system, the file system will be
>inconsistent when it is restored.  fsck will usually fix this ....

V7 and 4.1bsd restor wrote the i-list directly and would indeed restore
unreferenced files.  An fsck afterwards would give the same errors as
an fsck done during the dump.  4.2bsd restore cannot produce an
inconsistent filesystem, but it often dies trying.

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