From owner-freebsd-hackers Sat Apr 8 04:00:59 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id EAA12571 for hackers-outgoing; Sat, 8 Apr 1995 04:00:59 -0700 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA12559 for ; Sat, 8 Apr 1995 04:00:54 -0700 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA09210; Sat, 8 Apr 1995 13:00:50 +0200 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id NAA28472; Sat, 8 Apr 1995 13:00:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.6.11/8.6.9) id KAA05362; Sat, 8 Apr 1995 10:43:01 +0200 From: J Wunsch Message-Id: <199504080843.KAA05362@uriah.heep.sax.de> Subject: Re: Arcive Viper QIC150 and tar To: rmallory@wiley.csusb.edu (Rob Mallory) Date: Sat, 8 Apr 1995 10:43:00 +0200 (MET DST) Cc: freebsd-hackers@freefall.cdrom.com In-Reply-To: <199504072227.AA21670@wiley.csusb.edu> from "Rob Mallory" at Apr 7, 95 03:27:40 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2926 Sender: hackers-owner@FreeBSD.org Precedence: bulk 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. ;-)