Date: Sat, 8 Apr 1995 10:43:00 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: rmallory@wiley.csusb.edu (Rob Mallory) Cc: freebsd-hackers@freefall.cdrom.com Subject: Re: Arcive Viper QIC150 and tar Message-ID: <199504080843.KAA05362@uriah.heep.sax.de> In-Reply-To: <199504072227.AA21670@wiley.csusb.edu> from "Rob Mallory" at Apr 7, 95 03:27:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Rob Mallory wrote:
>
> (using a 6150 tape and archive viper ((known rougue??? huh?)))
Nothing to worry about. Only means that it gets a special treatment
inside the st driver.
> -why does it break tar? (tar czvf /dev/nrst0 /src/X11R6 segfaults..)
I dunno if a segfault is an appropriate answer :), but at the very
least you deserve a data loss. You're attempting to write non-blocked
data (the output of gzip) to an unbuffered device.
You can do one of the following:
tar -cvzf - /foo /bar | dd obs=16k conv=osync of=/dev/nrst0
or
tar -cvzf /dev/nrst0 --block-compress /foo /bar
Given the media prices, zipping the data is not the best thing to do
(IMHO). It costs allot of CPU, risking a non-streaming tape, and in
case of a later medium error, chances to reconstruct things that are
located after the error are minimal.
(Btw., given your example above: GNU tar avoids absolute path names
in the archive by default.)
> -dump works, but dump 0budfs 126 1000 /dev/rst0 700 /dev/sd0a
> wants to put it on two tapes! dump uf /dev/rst0 works.
What a strange option combination. ;) You really want 126-KB-records?
I'm using:
dump [0-9]uBf {150000|250000} /dev/[n]rst0 filessys
dump normally counts in kilobyte blocks. Theoretically, the figures
above could be somewhat larger, but dump handles the end of tape very
ungracefully, so it's better to give a `safe' number instead of having
to restart the dump command once it took 45 minutes to fill up a full
250 MB cartridge and finally failed due to an unexpected end of tape.
(Due to error recovery strategies, the actual amount of data a QIC
cartridge can hold varies from tape to tape.)
> -can I use any longer tapes reliably?
I've been using the Viper 150 now for more than two years, it's really
a solid drive. I'm using 37 MB, 150 MB and 250 MB media (the 37 media
are old Data General tapes, i don't think you can purchase them
anywhere). A full dump off a 800 MB /usr partition onto 4 tapes costs
some time, but once i've got the problem to restore a full /usr
partition from a two-level backup (level 0 and level 9), i know why
dump/restore is better than tar. :-) (The partition was already full
after restoring L0, but it had to replace more than 100 MB when
restoring the next level -- restore handles the deleted files
automagically!)
The Viper 150 has one annoying firmware bug^H^H^Hfeature: in order to
append files to the tape (or should i call them ``extents''?), you'll
have to ``mt fsf'' until you see the first BLANK CHECK (st0: no data).
Once i'm done with back-integrating all the st(1) functionality into
mt(1), i'll re-add the ``mt eom'' feature which allows you to skip to
the end of recorded medium with a single command. This is handled by
the drive in a more intelligent way.
--
cheers, J"org
joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504080843.KAA05362>