Date: Mon, 15 Jan 1996 05:52:34 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, gibbs@freefall.freebsd.org Cc: freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Message-ID: <199601141852.FAA14785@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Isn't this behaviour a fundamental part of the idea of a "mount >>session"? See st.4. >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. >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. >>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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601141852.FAA14785>