SUMMARY: BSD tape handling.

From: Frank Pardo (
Date: Fri Aug 30 1996 - 08:36:01 CDT

First, many thanks to all who replied:

        John Benjamins <johnb@Soliton.COM>
        Brion Leary <> (Mark S. Anderson)

Abridged versions of the original query and the responses are below.

Second, the summary: No consensus.

There seems to be no firm answer (right now) to my question about the
"b" (BSD) suffix on tape device names. Some people (including me) don't
need to bother with the "b" suffix, others have trouble when they leave
it off. Maybe different versions of SunOS/Solaris behave differently in
this respect. Can't tell, because not everyone mentioned the operating
system release they're using.

  Frank Pardo		<> 
  System Administrator 
  Transaction Information Systems
  New York City

QUERY> Date: Tue, 27 Aug 1996 16:45:35 -0400 (EDT) QUERY> From: (Frank Pardo) QUERY> QUERY> Two summaries in recent weeks discussed a problem that I've been unable QUERY> to reproduce. I used the "plain" (non-BSD) tape device, and was able to QUERY> read and write multiple files on the tape. Can anyone shed some light on QUERY> QUERY> > From: Rubens Queiroz - SUPSOF #200503# <> QUERY> > Subject: SUMMARY: Problems with tcopy, dump, ... QUERY> > Date: Thu, 15 Aug 1996 16:30:47 -0300 (BSC) QUERY> > QUERY> > I would like to thank Kevin Davidson for his prompt reply to my request. QUERY> > I am enclosing with this mail his reply, as it worked just fine. QUERY> > QUERY> > Use the device /dev/rmt/0hbn instead. The system V tape driver leaves QUERY> > the tape head just *before* the end of file marker. Your next dump QUERY> QUERY> > From: Micah Anderson <> QUERY> > Subject: SUMMARY: ufsdump more than one filesystem? QUERY> > Date: Mon, 26 Aug 1996 14:16:20 -0700 (PDT) QUERY> > QUERY> > Thank you to everyone who replied to my problem, you were all very QUERY> > helpful. Apparantly the best solution was just to use the /dev/rmt/0bn QUERY> > device which is the Berkeley non-rewinding device that properly works...

REPLY-1> Date: Wed, 28 Aug 1996 10:05:09 -0400 REPLY-1> From: John Benjamins <johnb@Soliton.COM> REPLY-1> REPLY-1> there would appear to be no real problem here. what your test shell REPLY-1> scripts do seems to be correct. so it would appear that semantically, REPLY-1> the summaries you quoted may be incorrect. the only time it's really REPLY-1> an issue which device you use, would be when you take a tape written REPLY-1> with the AT&T (ie. non-BSD) tape device, and try to read it on a REPLY-1> system with only a BSD style device driver. this would not work. REPLY-1> REPLY-1> secondly, the previous summaries you quote dealt with problems with REPLY-1> ufsdump/ufsrestore. there is the possibility that although ufsdump REPLY-1> can write tapes properly to the AT&T style device, ufsrestore cannot REPLY-1> read those tapes (ie. a bug in ufsdump/ufsrestore). i am not aware of REPLY-1> any such bug, but it is possible.

REPLY-2> From: REPLY-2> Date: Wed, 28 Aug 96 8:31:03 REPLY-2> REPLY-2> Same here. Yesterday's message sent me scurring to check my level 0 dumps. REPLY-2> All is OK. My uname -a is: REPLY-2> SunOS op 5.4 Generic_101945-38 sun4m sparc REPLY-2> Is it a specific version or patch level of Solaris? REPLY-2> REPLY-2> Brion Leary <>

REPLY-3> Date: Wed, 28 Aug 96 14:17:03 EDT REPLY-3> From: (Mark S. Anderson) REPLY-3> REPLY-3> Ah! But did you try ufsdump and tar? I know that this is supposed to REPLY-3> be a problem with the tape driver, but to reproduce the problem, you REPLY-3> should try doing the same thing that caused the problem for someone REPLY-3> else.

REPLY-3-ANS> Date: Thu, 29 Aug 1996 10:37:32 -0400 (EDT) REPLY-3-ANS> From: (Frank Pardo) REPLY-3-ANS> To: REPLY-3-ANS> REPLY-3-ANS> I tried ufsdump and ufsrestore, and still could not reproduce the REPLY-3-ANS> problem that others complained of. The test script and its output are REPLY-3-ANS> reproduced below. As for tar, I don't recall any mention of it in this REPLY-3-ANS> context. REPLY-3-ANS> REPLY-3-ANS> [test script and output omitted for brevity]


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