From npaufler@asgard.incentre.net  Wed Apr 23 14:43:16 2003
Return-Path: <npaufler@asgard.incentre.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 25EC037B401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 Apr 2003 14:43:16 -0700 (PDT)
Received: from asgard.incentre.net (asgard.incentre.net [206.75.213.14])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 665B543F3F
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 Apr 2003 14:43:15 -0700 (PDT)
	(envelope-from npaufler@asgard.incentre.net)
Received: from asgard.incentre.net (localhost [127.0.0.1])
	by asgard.incentre.net (8.12.8p1/8.12.8) with ESMTP id h3NLi12g000605
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 23 Apr 2003 15:44:01 -0600 (MDT)
	(envelope-from npaufler@asgard.incentre.net)
Received: (from npaufler@localhost)
	by asgard.incentre.net (8.12.8p1/8.12.8/Submit) id h3NLi1WR000604;
	Wed, 23 Apr 2003 15:44:01 -0600 (MDT)
Message-Id: <200304232144.h3NLi1WR000604@asgard.incentre.net>
Date: Wed, 23 Apr 2003 15:44:01 -0600 (MDT)
From: Nicholas Paufler <npaufler@incentre.net>
Reply-To: Nicholas Paufler <npaufler@incentre.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: QUIRK: BNCHMARK DLT1 requires SA_QUIRK_1FM
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         51332
>Category:       kern
>Synopsis:       QUIRK: BNCHMARK DLT1 requires SA_QUIRK_1FM
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mjacob
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 23 14:50:14 PDT 2003
>Closed-Date:    Tue Oct 17 21:32:46 GMT 2006
>Last-Modified:  Tue Oct 17 21:32:46 GMT 2006
>Originator:     Nicholas Paufler
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
The Internet Centre
>Environment:
System: FreeBSD asgard.incentre.net 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Wed Apr 23 14:40:16 MDT 2003 root@asgard.incentre.net:/usr/src/sys/compile/ASGARD i386

camcontrol devlist:
<BNCHMARK DLT1 3213>               at scbus0 target 6 lun 0 (pass0,sa0)

mt status:
Mode      Density              Blocksize      bpi      Compression
Current:  same                 variable       0        IDRC
---------available modes---------
0:        same                 variable       0        IDRC
1:        same                 variable       0        IDRC
2:        same                 variable       0        IDRC
3:        same                 variable       0        IDRC
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0  Record Number: 0        Residual Count 0

>Description:
The Benchmark DLT1 drive (rebadged by Dell, among others) requires the
SA_QUIRK_1FM Quirk. Two EOT filemarks are always written after every write,
making restores non-obvious and causes some software (i.e. flexbackup) to
break on restores.

>How-To-Repeat:
mt rewind
(whatever commands you use to write data out to the tape, i.e. afio, pax, or some frontend utility like flexbackup)
mt rewind
(append another file, i.e. an incremental backup, using similar commands)
mt rewind
mt fsf 2
(that should bring you to the second file on the tape)
(execute whatever commands to restore and it will fail. repeat the restore
command imediately and it will work, because the position has advanced by
one)

mt geteotmodel shows: /dev/nsa0: the model is 2 filemarks at EOT

>Fix:

I applied the following patch to /usr/src/sys/cam/scsi/scsi_sa.c

I belive that at least one of the TANDBERG devices already listed in Quirks
is also using the Benchmark DLT1 tech. As I had no need to tweak the block
size I left it at 0 (which I am assuming means don't force it to anything).
Likewise I didn't need to play with the compression at all.

After applying the patch, mt geteotmodel does still show 2 filemarks as
being used, but it is quite obvious that only one is being written because
mt is correctly able to position for reads and I am able to restore normally.

Please let me know if I've missed anything. It took me a few days of work
to track down what was happening (and a helpful suggestion from the flexbackup
author) and I'd like to see this resolved.

--- bnchmark.patch begins here ---
--- scsi_sa.c	Wed Apr 23 14:23:14 2003
+++ dlt.scsi_sa.c	Wed Apr 23 14:27:58 2003
@@ -298,6 +298,10 @@
 		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "ARCHIVE",
 		  "VIPER 2525*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 1024
 	},
+	{
+		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "BNCHMARK",
+		  " DLT1 3213*", "*"}, SA_QUIRK_1FM, 0
+	},
 #if	0
 	{
 		{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP",
--- bnchmark.patch ends here ---


>Release-Note:
>Audit-Trail:

From: "Nicholas Paufler" <npaufler@incentre.net>
To: <freebsd-gnats-submit@FreeBSD.org>, <npaufler@incentre.net>
Cc:  
Subject: Re: kern/51332: QUIRK: BNCHMARK DLT1 requires SA_QUIRK_1FM
Date: Wed, 23 Apr 2003 16:48:06 -0600

 Hrm :/
 
 I did quite a bit of testing both with and without this patch before I
 submitted it, but something is still broken.
 
 mt fsf 2
 (and then restore the data)
 
 should restore the second thing put to the tape. However, it doesn't.
 Because there are still 2 EOT marks, I need to do:
 mt fsf 3
 (and then restore my data)
 
 because there are two markers.
 
 I was fairly certain my patch fixed it since it worked in my small, fast
 test cases, but now that I've tried it with some larger data i'm back to
 square one.
 
 Perhaps someone more familiar with the scsi underlyings can help me out
 here? Hacking kernel source really isn't my forte :)
 
 Thanks
 
 Nicholas
 

From: "Nicholas Paufler" <npaufler@incentre.net>
To: <freebsd-gnats-submit@FreeBSD.org>
Cc:  
Subject: Re: kern/51332: QUIRK: BNCHMARK DLT1 requires SA_QUIRK_1FM
Date: Thu, 24 Apr 2003 11:21:39 -0600

 On Jonathon Reynold's suggestion, I added:
 option          SA_1FM_AT_EOD
 
 to my Kernel and just forced 1 filemarker for all sa devices. It's not
 really optimal in any case where there are more than 1 SCSI device and there
 probably should be a quirk entry for this device, but that kernel option was
 able to get me working again.
 
 If anyone wants to pursue this I can do some more testing if requested,
 otherwise it can be closed.
 
 Nicholas
 
Responsible-Changed-From-To: freebsd-bugs->njl 
Responsible-Changed-By: johan 
Responsible-Changed-When: Tue May 6 12:31:52 PDT 2003 
Responsible-Changed-Why:  
Over to quirks maintainer. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51332 

From: Nate Lawson <nate@root.org>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: kern/51332
Date: Sat, 17 May 2003 15:05:48 -0700 (PDT)

 Information from mjacob@.  It indicates that this is not a bug per se.
 Please use "mt seteotmodel 1" if you want this behavior or use mt commands
 as shown below.
 
 ---------- Forwarded message ----------
 Date: Wed, 14 May 2003 23:17:14 -0700 (PDT)
 From: Matthew Jacob <mjacob@feral.com>
 
 They're not really clear on the repeat-by case.
 
 Personally, I believe that the default should be 1 FM, but that breaks
 historic precedent for all but QIC drives. I've suggested this before
 but was shot down both in NetBSD and FreeBSD.
 
 At any rate, if you open the non-rewinding device, two filemarks are
 written, but you backspace over one of them, leaving yourself on the EOT
 side of the first.
 
 If, on the other hand, you rewind, the question is whether those two
 filemarks have actual residency on media or not.  Some drives have them,
 some don't.
 
 I *think* they're complaint is that there are two filemarks between data
 files, thus confusing restore. That may be the case, but that's mostly
 operator error. Say you do this:
 
  cd /usr
  tar cf /dev/rsa0 include
 
 this should leave you with
 
   BOT - file - MRK - MRK - LEOT
 
 and the tape positioned at BOT.
 
 If you then do:
 
  mt rewind
  mt -f /dev/nrsa0 fsf 1
  tar cf /dev/rsa0 lib
 
 you should then up with
 
 
   BOT - file - MRK - file - MRK - MRK - LEOT
 
 and the tape positioned at BOT.
 
 If on the other hand you had done:
 
  mt rewind
  mt -f /dev/nrsa0 eom
  tar cf /dev/rsa0 lib
 
 you *could* have wound up with:
 
   BOT - file - MRK - MRK - file - MRK - MRK - LEOT
 
 *or*
 
   BOT - file - MRK - file - MRK - MRK - LEOT
 
 it depends on the tape drive.
 
 It's my recollection that the DLT won't do the former, but I really
 haven't looked at this kind of thing in months and I could easily
 believe that different f/w might have different behaviours.
 
 In any case, I don't believe there's a bug here. If they don't like the
 dual fmk behaviour, they can always do a seteotmodel to 1.
 
 -matt
Responsible-Changed-From-To: njl->mjacob 
Responsible-Changed-By: njl 
Responsible-Changed-When: Sun Oct 17 19:04:45 GMT 2004 
Responsible-Changed-Why:  
Passing this back to the tape maintainer.  No time available for me. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51332 
State-Changed-From-To: open->closed 
State-Changed-By: mjacob 
State-Changed-When: Tue Oct 17 21:30:39 UTC 2006 
State-Changed-Why:  
Will not fix. Just about every DLT *but* this one handles 2 FM fine. 
A 'mt seteotmodel' also works. It's also stale. Furthermore, my 
recollection is that other BNCHMRK users had no problems witn 2FM 
(at Mirapoint). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51332 
>Unformatted:
