Date: Sun, 14 Jan 1996 11:29:56 -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: <199601141929.LAA18232@freefall.freebsd.org> In-Reply-To: Your message of "Mon, 15 Jan 1996 05:52:34 %2B1100." <199601141852.FAA14785@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>Then I think the man page should be changed. If you want special >>settings for an rst* session, you must use the control device. >>Why should nrst* devices be special in that you can close one, >>run some mt commands on the same device, and expect them to stick >>for the following open? > >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. >>My main gripe has to do with preventing media removal when the >>device is closed, so I could implement this another way, to maintain >>the "mount session" behavior, but I think the current "mount session" >>is confusing at best. > >I don't see the problem. If you're controlling the device interactively, >then just type "st rewoffl". Otherwise you need a program to control >anything more complicated than the rewinding device, and the program >can do the "st rewoffl" just as easily as it can do a close. 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 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. This is just like the Macintosh only worse... you actually have an eject button taunting you, but its disabled. >>>Perhaps there should be another special minor or 3 to give modes >>>with different eject behaviour. OTOH, there may already be too many >>>minors and too many variations to control with minor bits. Perhaps >>>... > >>I think that the control device should be sufficient. I realy don't >>see how the curren't behavior replaces using the contrl device. I guess >>you could open nrst*, do a rewind, do some mt stuff to it, then do your >>dumps, but why go through a middle man when you can simply set the >>control device? > >The problem is the (time) scope of the controls. I use tar and always >check backups by rewinding and doing a "tar df" (my data is still small >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. >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?199601141929.LAA18232>