Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Dec 1999 08:03:06 -0800 (PST)
From:      Matthew Jacob <mjacob@feral.com>
To:        Stephen McKay <syssgm@detir.qld.gov.au>
Cc:        freebsd-scsi@FreeBSD.ORG
Subject:   Re: Tape driver problems 
Message-ID:  <Pine.BSF.4.10.9912040757590.24567-100000@beppo.feral.com>
In-Reply-To: <199912040930.TAA02368@nymph.detir.qld.gov.au>

next in thread | previous in thread | raw e-mail | index | archive | help

> >Well, send-pr it as an RFE. It'll be a post 4.0 thingie tho.
> 
> I'll put something together if not beaten to it.

You're still on the hook..
> 
> >> >I'll have to check what happened here. Do you have CAMDEBUG defined?
> >> 
> >> Hmm.  That looks like the sort of thing I might do. ;-)  I'll confirm
> >> tonight to see if this is my fault.
> 
> I have INVARIANTS and INVARIANT_SUPPORT but not CAMDEBUG.  I've not tried
> the post-1.39 versions yet, so you've probably fixed this.

Check and see.

> 
> >Try and change the MAXPHYS sizes in samount to 8192. I've done this to see
> >what happens (not really sure yet whether it works as well as I'd like).
> 
> I tried using MAXPHYS, 64K and 8192.  I tried a blank tape (fresh from
> the wrapper) and 2 tapes already written at 2GB and 5GB density with a
> 32KB blocksize.  MAXPHYS caused the "too many segs" error.  The others
> didn't cause any errors.  Further, a kernel from mid November did not
> correctly determine the initial density.

Yup. What I expect. I already did change the read size to 8K.

> 
> The intriguing thing is that all 3 gave the correct density for each tape.
> >From this I concluded that the fake read was unnecessary.  I tried with
> the read commented out and it still works.  (I left in the rewind and
> other stuff.)  So, for my equipment at least, some other recent change
> has produced the improved density detection.

Well, there was breakage at one point where the latched up values never
got updated.

> 
> Also, the extra read is not free.  It adds an extra 30 seconds to the
> startup time.  It takes about 40 seconds from tape insertion to ready,
> then the density determining read adds 30 seconds.  Before this patch, an
> initial read starts after about 6 seconds.  Now it takes about 36 seconds.

Yes. I've thought about this. The only way to get around this is to go
back to the FBSD 2.X version of quirking tapes (which I don't want to
do) that need this detection, or have *another* state of
MOUNTED_BUT_NOT_READ so that the test read only occurs if an ioctl to get
current density happens *before* a read or a write.

Each quirk type added becomes a sure set of questions and misapplication.
I avoid them whenever I can.

The extra state stuff above is doable, but I didn't want to add this
complexity in a hurry. Send-pr it.

> 
> Well, I'm off to test the new changes.  I let you know if I learn anything.
> 
> Stephen.
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9912040757590.24567-100000>