From owner-freebsd-scsi Sun Jan 14 12:30:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA20874 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 12:30:01 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA20857 Sun, 14 Jan 1996 12:29:35 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id HAA17864; Mon, 15 Jan 1996 07:26:34 +1100 Date: Mon, 15 Jan 1996 07:26:34 +1100 From: Bruce Evans Message-Id: <199601142026.HAA17864@godzilla.zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Cc: freebsd-scsi@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >>Because then there would be complications involving how long-lived >>the settings are. You would need two control devices, one to set >>the defaults that are restored at the end of a mount session and >>a new one to control mount sessions. You would also need a new >>command to end mount sessions. >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. >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. >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: mt -f /dev/nrst0 blocksize 0 od /dev/nrst0 # failed mt -f /dev/rst0 rewind >>enough for this to be practical :-). I don't want an auto offline on >>rewind. Allowing eject at any time that the hardware does and mount >>sessions extending across ejects might be useful, however. >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. Bruce