SUMMARY: ufsdump more than one filesystem?

From: Micah Anderson (micah@smmedia.com)
Date: Mon Aug 26 1996 - 16:16:20 CDT


Thank you to everyone who replied to my problem, you were all very
helpful. Apparantly the best solution was just to use the /dev/rmt/0bn
device which is the Berkeley non-rewinding device that properly works...
Someone also suggested that I use the /dev/rmt/0cn device, but I am
unclear as to what the purpose of this device actually is, does anyone
know?

Thanks again for your quick responses!

Micah

 Summaries, trimmed by me, follow:

>From anderson@neon.mitre.org Mon Aug 26 14:10:05 1996
From: "Mark S. Anderson" <anderson@neon.mitre.org>

Use the "b" option to invoke BSD behavior. e.g.: /dev/rmt/0bn.
See mtio(7I).

From: Marc Power <mpower@fcmc.COM>

Hi Micah,
You need to use the BSD compatible device, /dev/rmt/0bn.

The System V device leaves you pointing just before the EOF of
the first file, so when you dump again, it is overwritten and
you just get one, humungous and useless file on the tape.

The BSD compatibile devices leaves you pointing just after the
EOF at the beginning point on the tape for the new file, as one
would expect.

Cheers!

Marc Power

>From afinkel@pfn.com Mon Aug 26 14:10:19 1996
From: Alex Finkel <afinkel@pfn.com>

Try using /dev/rmt/0bn

Supposedly the BSD compatiblity mode leaves the tape positioned after the
EOF/EOT (?) marker correctly.

- Alex

--
Alex Finkel       | 26 Landsdowne St.      |    Macintosh, Jr.
Network Manager   | University Park at MIT | 
PFN, Incorporated | Cambridge, MA  02139   |  The power to crush
afinkel@pfn.com   | http://www.pfn.com/    |    the other kids.

>From russ@prin.reci.com Mon Aug 26 14:10:24 1996 From: Russ Bebb <russ@prin.reci.com>

Micah,

I use /dev/rmt/0cn

for my multiple dumps.

If you want my script, holler.

Russ

>From miquel@proton.uab.es Mon Aug 26 14:10:29 1996 From: "Miquel Cabanas. BBM-UAB" <miquel@proton.uab.es>

hi,

i don't think it should work this way (ie. i would say it's a bug), but i've already had this problem (sol.2.5.1) and circumvented it by using the following sequence of commands...

# failed attempt to use a non-rewinding tape device (/dev/rmt/0ln), # somehow, the tape is rewound and the 2nd ufsdump overwrites the # 1st one. # # final commands: # # [load a new tape] # # TAPE = /dev/rmt/0l (the non-rewinding did rewind the tape!)

carbon > mt -f $TAPE weof # write an eof mark at the current position carbon > mt -f $TAPE rewind # rewind the tape carbon > mt -f $TAPEnr fsf # go to the 1st eof mark in the tape # remote backup of /data directory proton > /usr/sbin/ufsdump 0ubf 96 carbon.uab.es:/dev/rmt/0l /data

carbon > mt -f $TAPEnr asf 2 # go to the 2nd eof mark (absolute count)

# remote backup of /opt2 directory proton > /usr/sbin/ufsdump 0ubf 96 carbon.uab.es:/dev/rmt/0l /opt2

# check the 1st backup carbon > mt -f $TAPEnr asf 1 # go to 1st eof mark (absolute count) carbon > ufsrestore i ufsrestore > ls [it was ok] ufsrestore > quit

# check the 2nd backup carbon > mt -f $TAPEnr asf 2 # go to the 2nd eof mark (absolute count)

carbon > ufsrestore i ufsrestore > ls [it was ok] ufsrestore > quit

hope this helps...

miquel

>From Daniel.Blander@ACSacs.Com Mon Aug 26 14:10:37 1996 From: "Daniel J Blander - Sr. Systems Engineer for ACS" <Daniel.Blander@ACSacs.Com>

This actually appeared a few days ago on this list. Aparently 2.5 uses a different method of non-rewinding that does not forward past the EOF marker on the tape when it finishes - hence the block of data is actually overwritten.

In all my script using of ufsdump, I do an:

mt -f /dev/rmt/0n rew mt 0f /dev/rmt/0n fsf 1 (or whatever number of tape blocks I need to go past)

There is apparently another work around which involves using Berkley style tape control which moves past the EOF....but I don't know the solution to that...

_______________________________________________________________________________ Micah Johan Eckman Anderson micah@smmedia.com Sr. Systems Administrator 1-888-614-3709 Schmidt Mead Media, Inc. pagemicah@smmedia.com -------------------------------------------------------------------------------



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:08 CDT