Date: Sun, 14 Jan 1996 17:35:43 -0800 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: Julian Elischer <julian@ref.tfs.com> Cc: bde@zeta.org.au, freebsd-scsi@freefall.freebsd.org Subject: Re: Calling st_unmount for nrst* devices Message-ID: <199601150135.RAA06158@freefall.freebsd.org> In-Reply-To: Your message of "Sun, 14 Jan 1996 16:45:52 PST." <199601150045.QAA19380@ref.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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.. This isn't true. A mount session ends when: 1) You change from nrst* to some other openning mode. 2) You close the rst* or erst* device. >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. How do I do a single rewinding dump with settings other than what the control device is set for? The only option is to use the nrst device because the other devices don't have a true mount session. I can't do an: mt -f /dev/nrst0 blocksize X tar cvf /dev/rst0 /usr/src and expect the blocksize to stick even though I think it should because the media hasn't changed. >the Control device is to set default settings to which the device returns >after a session has ended. And should be applied only when new media is detected. >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.. I think the session should encapsulate the time that a single piece of media is loaded. This would make sense. >> 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. Hmmm. Yes this does work, but I don't see why the session ends simply by closing the rst0 device. It should end when we eject the tape or get a unit attention from new media being loaded instead of only having meaning for the nrst* devices. >> 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 I can live with the eject button being enabled so long as the device is closed, but I do think we should re-evaluate the semantics of a tape mount session. >aaarrggg, I already have one too many (the eject device should go away I think >) Agreed. >> >>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. But aren't the overrides valid so long as the current tape is in the machine? Shouldn't the session be bracketted by media changes and not the devices you use? >two differnt devices with different permissions... >you don't permit Joe User to change the defaults.. Understood, but my problem isn't with 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. >hmmmm POSSIBLY a use for the 3rd minor combo.. >[UNIT Attention doesn't reset the session..] Unit attention should always reset the session. -- 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?199601150135.RAA06158>