Date: Sat, 4 Nov 2000 09:51:50 -0600 (CST) From: Mike Meyer <mwm@mired.org> To: svga <svga@polbox.com> Cc: Mike Meyer <mwm@mired.org>, questions@freebsd.org Subject: Re: Dump>gzip>tape Message-ID: <14852.12438.38206.872416@guru.mired.org> In-Reply-To: <3A03FB66.A5EA37B0@polbox.com> References: <14851.13564.754374.181047@guru.mired.org> <MABBLHJKMGCKNMENMJAGMEAFCAAA.svga@polbox.com> <14851.16514.777011.58213@guru.mired.org> <3A03FB66.A5EA37B0@polbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
svga <svga@polbox.com> types: > Many thanks! It seems to work ok! > So how to use restore in this case? The obvious (dd if=/dev/rsa0 ibs=10k | gzcat | restore xf -) should work, but gunzip will complain about "trailing garbage ignored". "conv=osync" adds the trailing garbage (actually nulls) to pad the file out to a full block so that the tape device driver doesn't complain about getting a short block at the end. You can use the -q option of gzcat, but that will make all other warnings vanish as well. Now that I look a the gzip man page, it discusses all this at the end. You should have read that before asking the question :-(. <mike > #dump 0af - / | gzip -9 | dd of=/dev/rsa0 obs=10k conv=osync > DUMP: Date of this level 0 dump: Sat Nov 4 12:57:37 2000 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/da0s1a (/) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 34125 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: DUMP: 34153 tape blocks > DUMP: finished in 100 seconds, throughput 341 KBytes/sec > DUMP: DUMP IS DONE > 29273+1 records in > 1464+0 records out > 14991360 bytes transferred in 100.211964 secs (149597 bytes/sec) > > regards, > Olek > > Mike Meyer wrote: > > > Please send responses back to questions@freebsd.org; others may want > > to see or be able to help. > > > > svga <svga@polbox.com> types: > > > > > > -c isn't needed. The problem may be /dev/rsa0 is doing strange > > > things. Try sending the output of gzip through dd: > > > > > > #dump 0af - / | gzip -9 | dd of=/dev/rsa0 bs=10k > > > > > > DUMP: Date of this level 0 dump: Fri Nov 3 23:36:11 2000 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/da0s1a (/) to standard output > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 34125 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: DUMP: 34153 tape blocks > > > DUMP: finished in 101 seconds, throughput 338 KBytes/sec > > > DUMP: DUMP IS DONE > > > dd: /dev/rsa0: Invalid argument > > > 915+915 records in > > > 915+914 records out > > > 14985216 bytes transferred in 101.744104 secs (147283 bytes/sec) > > > > Looks like I was right - /dev/rsa0 is upset about the stream output to > > it. You'll have to figure out what it's limitations are, so you know > > what options to set on dd to get it to do the right thing. If you > > don't know what's up with the tape drive, I'd suggest replacing > > "bs=10k" with "obs=10k conv=osync". > > > > <mike > > > > --------------------- [POLBOX - REKLAMA] -------------------- > > http://www.femalelife.pl - najwiekszy serwis o antykoncepcji! > > http://www.schering.pl - najciekawsze informacje medyczne! > > ------------------------------------------------------------- > > > > --------------------- [POLBOX - REKLAMA] -------------------- > http://www.femalelife.pl - najwiekszy serwis o antykoncepcji! > http://www.schering.pl - najciekawsze informacje medyczne! > ------------------------------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14852.12438.38206.872416>