Date: Sun, 21 Apr 1996 11:14:18 -0700 (PDT) From: "JULIAN Elischer" <julian@ref.tfs.com> To: andrew@whine.com (Andrew Herdman) Cc: questions@freebsd.org, scsi@freebsd.org Subject: Re: Problems with the st driver in 2.2-960323-SNAP Message-ID: <199604211814.LAA18183@ref.tfs.com> In-Reply-To: <Pine.BSF.3.91.960421134255.192A-100000@why> from "Andrew Herdman" at Apr 21, 96 01:45:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> After some considerable poking around in the scsi code I found the
> following changes in st.c were causing the problem.
>
> in
>
> st_open:
>
> scsi_prevent(sc_link, PR_PREVENT, 0); /* who cares if it fails? */
>
> and
>
> st_close:
>
> scsi_prevent(sc_link, PR_ALLOW, SCSI_SILENT);
>
> Now I do agree that calling this function is appropriate. But it doesn't
> seem to work properly. I'm not a scsi expert so I'm not sure why it fails.
>
> Andrew
>
hmmm this is a semantic change that was introduced recently...
prior to this, a 'mount session' lasted until you explicitly
ended it by unloading the tape (or using the rst device instead of the nrst
device.) Recently it was decided that if the device was closed, then the]
user should have the option of ending the session by pressing the 'eject'
button. This would have the effect of causing a mount session reset at
the next open. In effect it would be the same as retrospectively
changing the last close to a close and unmount.
>
> On Wed, 17 Apr 1996, Andrew Herdman wrote:
>
> > After upgrading to the recent snap, I have been having problems with my
> > Archive Python 4mm Dat drive on a buslogics 946c and the nrst device.
> >
> > Using tar i can do the following:
> >
> > tar cf /dev/nrst0 /dir1
> > tar cf /dev/nrst0 /dir2
> > tar cf /dev/nrst0 /dir3
> > mt -f /dev/rst0 rewind
> >
> > tar tvf /dev/nrst0
> > <lists files from /dir1>
> > tar tvf /dev/nrst0
> > <does nothing>
this is expected.. what happens is:
tar reads until it sees it's EOF record, and stops reading..
IT HAS NOT YET READ IN THE TAPE EOF MARKER
the next read will IMMEDIATLY HIT THAT EOF MARKER and return eof.
This is documented somewhere.. I think psooibly in the tar man page..
> > tar tvf /dev/nrst0
> > <lists files from /dir2>
> > tar tvf /dev/nrst0
> > <does nothing>
> > tar tvf /dev/nrst0
> > <lists files from /dir3>
> >
> > Using dump, i get the following:
> >
> > # dump 9uBf 2000000 /dev/nrst0 /dev/rsd0a
> > DUMP: Date of this level 9 dump: Wed Apr 17 19:41:25 1996
> > DUMP: Date of last level 0 dump: Sat Apr 13 08:09:32 1996
> > DUMP: Dumping /dev/rsd0a (/) to /dev/nrst0
> > DUMP: mapping (Pass I) [regular files]
> > DUMP: mapping (Pass II) [directories]
> > DUMP: estimated 15855 tape blocks on 0.01 tape(s).
> > DUMP: dumping (Pass III) [directories]
> > DUMP: dumping (Pass IV) [regular files]
> > DUMP: DUMP: 15882 tape blocks on 1 volumes(s)
> > DUMP: finished in 92 seconds, throughput 172 KBytes/sec
> > DUMP: level 9 dump on Wed Apr 17 19:41:25 1996
> > DUMP: Closing /dev/nrst0
> > st0: not ready
> > DUMP: DUMP IS DONE
I think that the call device close() on LAST CLOSE might be broken..
dump uses several processes.. possibly
the first to finish closes the device and the others also try,
but it's already being closed.. ?
> >
> >
> > If I do multiple dumps on one tape it rewinds to the beginning and erases
> > the previous dump (not a very effective backup system ;). This all
> > worked perfectly fine with 2.1.0-RELEASE. I've been poking thru the
> > kernel sources (doing diff's between the 2 kernel sources) and haven't
> > found anything yet. Is this a known problem? Would the people working
> > on this area contact me, I'd like to help as much as I can to help solve
> > the problem.
I think you could safely remove the lines in question...
I'm not sure why it fails though.. they ar valid commands..
> >
> > Thanks
> > Andrew
> >
> >
>
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country !
+- X_.---._/ USA+(510) 645-3137(wk) \_/ \\ ><DARWIN>
v LL LL
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604211814.LAA18183>