Article View: comp.sys.dec
Article #1530re: Non-Interactive dump for RISC Ultrix 4.2 [it is]
From: Alan Rollow - Alan's Home for Wa...
Date: Mon, 14 Sep 1992 19:39
Date: Mon, 14 Sep 1992 19:39
68 lines
3549 bytes
3549 bytes
In article <GEORGE.92Sep14023506@tusk.med.harvard.edu>, george@tusk.med.harvard.edu (George Planansky) writes: > >The Ultrix 4.2 dump paramater "B", it turns out, refers >to the capacity in 1024 byte blocks of the dump tape. Seems >redundant to me. The manual page entry for 'B' reads: "Indicates that the next argument is a number that specifies the size, in 1024-byte blocks, of a storage medium, such as a diskette or removable disk cartridge." Note the "diskette or removable disk cartridge". I'd guess that when dump(8) sees the 'B' option it begins believing the output media is disk instead of tape. Disk can after call have a fixed number of 1 KB blocks. On tapes the number 1 KB blocks can change because of records skipped due to errors and such. >This is NOT to be confused with the Sun's SunOS and SGI's IRIX dumps' >"b" parameter, which refers to a blocking factor. (Why doesn't the >Ultrix dump have this?) Because little active improvement has been made on dump(8) over the last few years. Aside for support for new tape drivers, loader support and the TA90, etc, there hasn't been much new. I don't know WHY little improvement has been made, but must assume it's because the people that schedule engineering's time don't believe it needs to be updated. This has been a classic problem of ours and I'm not sure how to fix it. Maybe a concerted SPR or letter writting campaign to corporate executives... Oh, the last time I looked the 'b' option for a blocking factor was present in dump(8). It just isn't documented. The problem is that there isn't corresponding support in restore. > >And why does the Ultrix dump ask me to mount a disk, when it computes >that it has run out of tape? As noted before, because it believes it is writting to disk instead of tape. Don't use the 'B' option on tapes. > >The following (from Mountain Computer's exabyte manual) seems to work: > > dump 0usdBf 346 4137733 2097152 /dev/nrmt1h /usr It is always worth noting that ULTRIX dump(8) will use all of the available and accessible tape (*). For supported tapes, it should have (but sometimes doesn't) reasonable parameters for estimating the amount of tape needed. Please recognize the estimates as just that, ESTIMATES. If the parameters are wrong, then the estimates will be wrong. It will still use all the tape. However, if you specify other parameters to use as estimates, it will trust you and work on the assumption that your estimate is correct. If you provide bad information, then you may end up telling it to use only part of a tape. >-- >George Planansky >Department of Biological Chemistry & Molecular Pharmacology >Harvard University Medical School, 240 Longwood Ave., Boston, MA 02115 >email: gplanansky@tusk.med.harvard.edu >phone: (617) 432-3919 >fax: (617) 432-4360 > -- Alan Rollow alan@nabeth.cxo.dec.com
Technical Details
Message-ID:
<1992Sep14.193905.11916@nntpd2.cxo.dec.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alanReferences:
<GEORGE.92Sep14023506@tusk.med.harvard.edu>Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.dec Path: arc1-ca.pugleaf.net!sparky!uunet!decwrl!pa.dec.com!nntpd2.cxo.dec.com!nabeth!alan From: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.) Subject: re: Non-Interactive dump for RISC Ultrix 4.2 [it is] Message-ID: <1992Sep14.193905.11916@nntpd2.cxo.dec.com> Lines: 69 Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.) Reply-To: alan@nabeth.enet.dec.com (Alan Rollow - Alan's Home for Wayward Tumbleweeds.) Organization: Digital Equipment Corporation References: <GEORGE.92Sep14023506@tusk.med.harvard.edu> Date: Mon, 14 Sep 1992 19:39:05 GMT