Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jan 1996 13:02:16 -0800
From:      "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        freebsd-scsi@freefall.freebsd.org
Subject:   Re: Calling st_unmount for nrst* devices 
Message-ID:  <199601142102.NAA22789@freefall.freebsd.org>
In-Reply-To: Your message of "Mon, 15 Jan 1996 07:26:34 %2B1100." <199601142026.HAA17864@godzilla.zeta.org.au> 

next in thread | previous in thread | raw e-mail | index | archive | help
>>I just don't see this.  A mount session ends when you close the device.
>>When you open a device, a new mount session is started and the settings
>>from the control device are enforced.  The only difference between the
>>nrst* devices and rst* devices is that a close will rewind the tape.
>
>This would defeat the point of the current control device which is
>to give almost fixed system defaults for the next mount session.

How do I change the settings on a mount session for the rst* devices
now?  Do we need an "mt load" or some other operation so that you
can create a mount session for these devices so that a subsequent
open uses the new settings?  I'll have to play with this a bit to
see how it works now.

>>It just doesn't make sence that a closed device cannot be removed
>>externally (ie from the eject button on my tape drive).  There is
>
>Agreed.  Perhaps there should be a special device that is open
>through the mount session.  It can't be the standard device because
>you want to see closes of the standard device as last-closes, e.g.,
>for auto-rewind on close.

I just changed my patches to simply do the media locking/unlocking in
st_open and st_close now.  st_close is only called for last closes
according to the comments.  The problem with terminating the mount
session is that st_mount does a media load operation that will
rewind the tape.

>>also the problem that the busy light stays on for as long as the media
>>is locked.  Consider this:
>
>>mt /dev/rst0 rewind
>>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2e
>>dump 0uBf 2033646 /dev/nrst0 /dev/sd0s2f
>>mt /dev/rst0 rewind
>
>>Now, can I go over to my machine after this runs and eject the media?
>>Nope.  Even though mt uses the rewinding device (which should end the mount
>>session according to the man page), the mount session isn't closed because
>>we only do an ioctl and that ioctl only performs an st_rewind.
>
>(At first I thought you meant nrst0 because the explicit rewinds are
>unecessary for rst0.)
>
>Eject works here after similar operations on a Wangdat 3100:

Does the Wangdat honor media locking?

>mt -f /dev/nrst0 blocksize 0
>od /dev/nrst0	# failed

??? What's od?

>mt -f /dev/rst0 rewind

>>Who said anything about an auto offline.  Ending a mount session doesn't
>>imply an eject.  The only time the eject will happen is if you opened the
>>ejecting device or, with my changes, if the nrst device is closed and you
>>go hit the eject button on the drive.
>
>I was confusing mount sessions with physical mounts/offlines and that's
>more or less what they are here.  Eject permission is too closely tied
>to being offline.  Perhaps there is no difference for some hardware.

The question boils down to, "When should we lock the media."  Some people
have said not to lock it at all.  Perhaps the locking should be pushed into
mt so as to be optional and more flexible.  My tape drive shows a solid
busy light when locked instead of having it follow actuall tape write
operations, so having the media locked at all is a little anoying.

>Bruce

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601142102.NAA22789>