Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Jan 1996 16:45:52 -0800 (PST)
From:      Julian Elischer <julian@ref.tfs.com>
To:        gibbs@freefall.freebsd.org (Justin T. Gibbs)
Cc:        bde@zeta.org.au, freebsd-scsi@freefall.freebsd.org
Subject:   Re: Calling st_unmount for nrst* devices
Message-ID:  <199601150045.QAA19380@ref.tfs.com>
In-Reply-To: <199601141929.LAA18232@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 14, 96 11:29:56 am

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.
Exactly WRONG
A moutn session ends when you tell it to end..
a mount session is a method to allow one group of settings
(e.g. blocksize, density, compression) to be used across multiple 
opens.. this allows the use of commands sunc as  "mt fsf 1" in ashell script
without losing your settings.
the Control device is to set default settings to which the device returns
after a session has ended.

I can live with making the eject button act as a way of 
ending a session, but sessions themselves are too valuable
to change it too much..

> 
> >>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:
that is only true for some devices.. and anyhow it's true..
> 
> 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?

yes you should be able to, because your last 'close' was of
rst0 not nrst0 ans so the device should have released the tape..
the session has ended.. if not it's a bug.

> 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.

no, you also did a close.. and you had (in your example 'rst0' open)
the tape should release in this case.

> 
> This is just like the Macintosh only worse...  you actually have an eject
> button taunting you, but its disabled.

I can live with the eject button ending the session

> 
> >>>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
> >>>...
aaarrggg, I already have one too many (the eject device should go away I think)

> >
> >>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?

because you (the operator) want to set decent system defaults
and the user (another person) wants to TEMPORARILY over-ride them
to read in or write some tape.
two differnt devices with different permissions...
you don't permit Joe User to change the defaults..



> >
> >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.
hmmmm POSSIBLY a use for the 3rd minor combo..
[UNIT Attention doesn't reset the session..]
> 
> 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.
Or you ask it to eject
> 
> >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?199601150045.QAA19380>