NetBSD Problem Report #9840

Received: (qmail 188 invoked from network); 8 Apr 2000 17:19:48 -0000
Message-Id: <200004081720.MAA14462@dei.dyn.dhs.org>
Date: Sat, 8 Apr 2000 12:20:21 -0500 (CDT)
From: sbnoble@dei.dyn.dhs.org
Reply-To: sbnoble@dei.dyn.dhs.org
To: gnats-bugs@gnats.netbsd.org
Subject: Unexpected mt behavior
X-Send-Pr-Version: 3.95

>Number:         9840
>Category:       bin
>Synopsis:       mt erase defaults to full zeroing of tape
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    bin-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 08 17:20:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Mon Nov 13 21:10:06 +0000 2000
>Originator:     Seth Bradley Noble
>Release:        1.4.1
>Organization:
>Environment:
System: NetBSD dei 1.4.1 NetBSD 1.4.1 (DEI) #0: Fri Feb 11 13:41:57 CST 2000 sbnoble@dei:/usr/src/sys/arch/sparc/compile/DEI sparc


>Description:

The "mt" command when not provided with a count argument defaults to a
count of 1 [mt.c line 157].  For the "erase" command, this translates
into a "full" erase [st.c/st_erase line 1812].

The "mt" man page incorrectly states that count is ignored for "erase".

>How-To-Repeat:

Insert a tape into a scsi tape drive.  Type

	mt erase

wonder why your drive is whirring and unresponsive for several hours
(or until you get sick of it, power cycle the drive, and reboot the
machine).

>Fix:

To perform a brief erase, a count of 0 must be explicitly given:
	mt erase 0

A full tape erasure on a modern tape drive could take several hours
during which time the drive will be unresponsive.  Since this
behavior is not documented in the manual page, it is not clear what
the drive is doing.  The only way to stop it is to power cycle
the drive.  Since the driver still thinks the drive is busy, it
is then necessary to reboot the system.

Since a full erase will rarely be desired, it should not be the
default behavior.  "mt" should set a default count of 0 for "erase"
and the manual page should document the behavior.


>Release-Note:
>Audit-Trail:

From: olson@bengaltech.com (Dave Olson)
To: sbnoble@dei.dyn.dhs.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: bin/9840: Unexpected mt behavior
Date: Sat, 8 Apr 2000 17:25:33 -0700 (PDT)

 sbnoble@dei.dyn.dhs.org wrote: 
 |  A full tape erasure on a modern tape drive could take several hours
 |  during which time the drive will be unresponsive.  Since this
 |  behavior is not documented in the manual page, it is not clear what
 |  the drive is doing.  The only way to stop it is to power cycle
 |  the drive.  Since the driver still thinks the drive is busy, it
 |  is then necessary to reboot the system.
 |  
 |  Since a full erase will rarely be desired, it should not be the
 |  default behavior.  "mt" should set a default count of 0 for "erase"
 |  and the manual page should document the behavior.

 That would make it different than most other versions of unix...

 I believe the current default is probably correct, based on a number
 of years of talking with customers who used mag tape in a number
 of different ways, and other OS folks at 5 or 6 other unix vendors.

 In fact, for a number of tape drives, there really isn't any concept
 of a "brief erase".


 Dave Olson
 Owned by 6 cats, owner of none...
 Personal:  olson@bengaltech.com        Work:  olson@geocast.com
            http://www.bengaltech.com          http://www.geocast.com

From: Seth Bradley Noble <sbnoble@dei.dyn.dhs.org>
To: olson@bengaltech.com (Dave Olson)
Cc: sbnoble@dei.dyn.dhs.org, gnats-bugs@gnats.netbsd.org
Subject: Re: bin/9840: Unexpected mt behavior
Date: Sun, 9 Apr 2000 11:37:33 -0500 (CDT)

 Dave Olson writes:
 >sbnoble@dei.dyn.dhs.org wrote: 
 >|  A full tape erasure on a modern tape drive could take several hours
 >|  during which time the drive will be unresponsive.  Since this
 >|  behavior is not documented in the manual page, it is not clear what
 >|  the drive is doing.  The only way to stop it is to power cycle
 >|  the drive.  Since the driver still thinks the drive is busy, it
 >|  is then necessary to reboot the system.
 >|  
 >|  Since a full erase will rarely be desired, it should not be the
 >|  default behavior.  "mt" should set a default count of 0 for "erase"
 >|  and the manual page should document the behavior.
 >
 >That would make it different than most other versions of unix...

 SunOS 4 makes no mention either way and SunOS 5 is vague on the
 subject: "Erasing may take a long time depending on the device and/or
 tapes."  Of the 4mm and 8mm drives I've used extensively on both, none
 have ever done a long erase.  I've had limited experience using drives
 on AIX, linux, and HP-UX, but I had never seen a long erase until now.

 >I believe the current default is probably correct, based on a number
 >of years of talking with customers who used mag tape in a number
 >of different ways, and other OS folks at 5 or 6 other unix vendors.

 Regardless of past convention, I don't believe that a full zeroing of
 the entire tape is a desireable default.  This is analagous to having
 the file system zero every file as it's unlinked or requiring every
 format to zero the whole disk first: useful for the paranoid but
 otherwise a waste of time.  Remember that we are talking about _hours_
 here just to be able to reuse a single tape.


 >In fact, for a number of tape drives, there really isn't any concept
 >of a "brief erase".

 Granted, I've only ever used 1/2" reel, 1/4" cartridge, DDS-1, DDS-2,
 and 8mm drives... but I've never seen one that didn't do a brief
 erase.


 In any event, the manual page should be corrected to note the default
 behavior and to point out that count is not ignored.


 -- 
 Seth Noble - President - Data Expedition, Inc. - sbnoble@dei.dyn.dhs.org - O-

From: olson@bengaltech.com (Dave Olson)
To: sbnoble@dei.dyn.dhs.org (Seth Bradley Noble)
Cc: olson@redtail.bengaltech.com, sbnoble@dei.dyn.dhs.org,
        gnats-bugs@gnats.netbsd.org
Subject: Re: bin/9840: Unexpected mt behavior
Date: Sun, 9 Apr 2000 13:18:10 -0700 (PDT)

 Seth Bradley Noble wrote: 
 |  SunOS 4 makes no mention either way and SunOS 5 is vague on the
 |  subject: "Erasing may take a long time depending on the device and/or
 |  tapes."  Of the 4mm and 8mm drives I've used extensively on both, none
 |  have ever done a long erase.  I've had limited experience using drives
 |  on AIX, linux, and HP-UX, but I had never seen a long erase until now.

 That's because erase (for scsi, and for the "same" drives with other
 interfaces), really is an erase; that is, render the tape such that
 no data on it is visible.  For some drives, the only way to that is
 to run the full length of the tape; for some drives, writing a pattern
 at BOT is enough to do this (for anybody with a regular drive and
 firmware, at any rate).

 QIC and 8mm (exabyte 8mm, that is, up through the 8500, which is when I last
 wrote drivers for them) both have this issue.  So does 9track.

 |  Regardless of past convention, I don't believe that a full zeroing of
 |  the entire tape is a desireable default.  This is analagous to having

 But that *IS* the semantics of the erase ioctl (and therefore command).

 |  the file system zero every file as it's unlinked or requiring every
 |  format to zero the whole disk first: useful for the paranoid but
 |  otherwise a waste of time.  Remember that we are talking about _hours_
 |  here just to be able to reuse a single tape.

 Yep.  It's a pity erase isn't faster on some of those drives, but for some
 of them (9track and 8mm), it runs at normal write speed, the full length
 of the tape.

 |  Granted, I've only ever used 1/2" reel, 1/4" cartridge, DDS-1, DDS-2,
 |  and 8mm drives... but I've never seen one that didn't do a brief
 |  erase.

 I think you must be talking about writing a filemark or "by convention" marker
 at BOT, then, at least for 9 track, 8mm, and 1/4" cartridg3, because I can
 guarantee you that there is no such ability for any of those tapes.

 |  In any event, the manual page should be corrected to note the default
 |  behavior and to point out that count is not ignored.

 Sure.

 Dave Olson
 Owned by 6 cats, owner of none...
 Personal:  olson@bengaltech.com        Work:  olson@geocast.com
            http://www.bengaltech.com          http://www.geocast.com

From: Seth Bradley Noble <sbnoble@dei.dyn.dhs.org>
To: olson@bengaltech.com (Dave Olson)
Cc: sbnoble@dei.dyn.dhs.org (Seth Bradley Noble), gnats-bugs@gnats.netbsd.org
Subject: Re: bin/9840: Unexpected mt behavior
Date: Mon, 10 Apr 2000 16:02:58 -0500 (CDT)

 Dave Olson writes:
 >|  Regardless of past convention, I don't believe that a full zeroing of
 >|  the entire tape is a desireable default.  This is analagous to having
 >
 >But that *IS* the semantics of the erase ioctl (and therefore command).

 Not true.  Check the source code for st_erase() in "st.c".  The count
 from the ioctl is passed directly into the "full" parameter and is
 used to determine whether the "LONG" bit should be set.  To quote:

         /*
          * Full erase means set LONG bit in erase command, which asks
          * the drive to erase the entire unit.  Without this bit, we're
          * asking the drive to write an erase gap.
          */

 The default behavior for the hardware, if the bit were not set, would
 be to do a short erase.

 The only reason that mt defaults to a full erase is that "count" is
 set to a default of 1 before the command name is evaluated.  A default
 of 1 makes sense for some commands: fsf, fsr, bsf, bsr, and compress.
 But erase, eew, blocksize, density, and sethpos would make more sense
 with either a default of 0.  Actually, most of the commands should
 probably return an error if no count is provided.


 >I think you must be talking about writing a filemark or "by convention" marker
 >at BOT, then, at least for 9 track, 8mm, and 1/4" cartridg3, because I can
 >guarantee you that there is no such ability for any of those tapes.

 Yes exactly. I'm talking about writing whatever marker the mechanism
 needs to tell it that there is no more data beyond that point.  As I
 said I've never seen drive that couldn't do that (though I don't doubt
 they exist).


 BTW- The reason this became a significant issue for me is that I've
 found that I have no other alternative for reusing tapes under netbsd
 with my current DDS-2 drive (aiwa mechanism).

 If I start writing data from the beginning of a used tape, the EOM
 does NOT change to the end of the new write (as it is supposed to).
 Instead, all of the data beyond the end of the new write session
 remains visible and is skipped across at the next eom command.

 I also tried using "weof" to write a double EOF (which often covers as
 an EOM), but "weof" seems to have no effect.  This may just be an
 artifact of this one drive (I'll try it on another drive when I get
 chance), but it makes me very glad that "mt erase 0" does work.


 -- 
 Seth Noble - President - Data Expedition, Inc. - sbnoble@dei.dyn.dhs.org - O-
>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.