Date: Sun, 6 Jun 1999 16:40:03 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/12062: sa tape driver with Cipher 60M SCSI QIC tape drive on 3.2 is droping last 10K block. Message-ID: <199906062340.QAA62592@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/12062; it has been noted by GNATS.
From: Matthew Jacob <mjacob@feral.com>
To: jhs@FreeBSD.ORG
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, nclayton@lehman.com,
stuart@jhs.muc.de, gary@jhs.muc.de
Subject: Re: kern/12062: sa tape driver with Cipher 60M SCSI QIC tape drive
on 3.2 is droping last 10K block.
Date: Sun, 6 Jun 1999 16:36:34 -0700 (PDT)
This PR does not have sufficient information to find out what is actually
going on. The same command works fine on some other QIC drives.
The sa(4) man page *does* warn you about older devices... This one is
*really* old- it looks looks like it doesn't have any parseable inquiry
data- and I rather suspect that it's failing because it's trying to write
two filemarks and is blowing chunks because of this. Because this drive
doesn't report INQUIRY data to correctly quirk it sufficiently to try and
write only one filemark- although you can try.
You can also try and comment out these lines:
/*
* Default to old FreeBSD behaviour of 2 filemarks
* at EOD for all (except QIC) devices.
*/
#ifndef SA_2FM_AT_EOD
#define SA_2FM_AT_EOD 1
#endif
and see what happens. Also you can try the recently updated driver/mt
commands that have the 'seteotmodel' ioctl to try and make sure that
attempts to write closing filemarks only write one filemark.
>
> -
>
> >Description:
>
> I had intended to file a bland
> Category: docs
> "please add to docu that this drive still works on 3.2"
> But Not So
> It seems the driver software has been srambled, & last blocks are dropped on write !
>
> Cipher tape drive Model 540 (Capacity: QIC 45M 60M tapes, Interface: SCSI 1)
>
> dmesg reports it as:
> Jun 6 18:48:17 wall /kernel: sa0 at aha0 bus 0 target 3 lun 0
> Jun 6 18:48:17 wall /kernel: sa0: < > Removable Sequential Access SCSI-CCS device
> Jun 6 18:48:17 wall /kernel: sa0: 3.300MB/s transfers
>
> It started to read a tape OK, that I created 1996.01.16 on BSD
> (but I got impatient & didnt read whole tape, as I control C'd it,
> as I thought I was just verifying then)
>
> On writing a 7.7M directory with tar cvf /dev/rsa0 . at end it reported
> tar: only wrote 0 of 10240 bytes to /dev/rsa0
> On reading same tape
> tar: Unexpected EOF on archive file
> On comparing directories, last file was different,
> to compare directories I used
> find . -type f -exec cmpd -d -v {} ../../public_html \;
> ( cmpd.c is written by me (compare & delete), available on
> http://www.freebsd.org/~jhs/src/bsd/jhs/bin/public/cmpd/ )
>
> Historical note: This is one of the same drive type I had listed as working in
> From: burgess@hrd769.brooks.af.mil (Dave Burgess)
> Date: 13 Jan 1994 06:00:46 -0000
> Newsgroups: comp.os.386bsd.announce,comp.answers,news.answers
> Subject: [comp.os.386bsd] BNR/2 derived BSD for PCs FAQ (Part 9 of 10)
> Message-ID: <386bsd-faq-9-758440818@hrd769.brooks.af.mil>
>
> Archive-name: 386bsd-faq/part9
>
> >How-To-Repeat:
>
> I do not know if this problem materialises on other drives & densities, I have others
> (Tandberg & Prime 60M ) & will try them, didn't notice this on my Tandberg 525M drive.
>
> >Fix:
> Driver software needs fixing, meantime:
> Always append 10K of garbage file as last item in a tar write
> (this is the same horrible trick I used many years ago, that became
> un-necessary years ago, & now is back again - Uugh ! :-)
>
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906062340.QAA62592>