From owner-freebsd-scsi Sun Jan 14 10:55:00 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA16246 for freebsd-scsi-outgoing; Sun, 14 Jan 1996 10:55:00 -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 KAA16236 Sun, 14 Jan 1996 10:54:47 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA14785; Mon, 15 Jan 1996 05:52:34 +1100 Date: Mon, 15 Jan 1996 05:52:34 +1100 From: Bruce Evans Message-Id: <199601141852.FAA14785@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 >>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