Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ames!elroy!cit-vax!mangler From: mangler@cit-vax.Caltech.Edu (Don Speck) Newsgroups: comp.unix.questions Subject: Re: Is dump dumb? Keywords: dump(8) cartridge streamer tape backups Message-ID: <7560@cit-vax.Caltech.Edu> Date: 10 Aug 88 09:40:07 GMT References: <655@rphroy.UUCP> <170@cui.UUCP> <23063@labrea.Stanford.EDU> <12624@mimsy.UUCP> Organization: California Institute of Technology Lines: 62 In article <170@cui.UUCP>, petitp@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@labrea.Stanford.EDU> karish@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@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck