25-Mar-1996 14:45:49 -0800,2613;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Mon, 25 Mar 1996 14:45:49 -0800 (PST) Return-Path: Received: from homer13.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA18256; Mon, 25 Mar 96 14:45:48 -0800 Received: from localhost by homer13.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA101210; Mon, 25 Mar 96 14:45:47 -0800 Date: Mon, 25 Mar 1996 14:45:46 -0800 (PST) From: Ken Marquess To: "R. Jamieson" Cc: "James W. DeRoest" Subject: multireel & std label tapes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (Jim, just FYI) I have a 'rough draft' ready for your comments, Bob. It is in mead:~kenm/tpipe, and is called 'tpipe_sl'. You pass the vsn's as argumants, and it reads the tape and writes the data to stdout. I did a (very) little benchmarking, and the performance penalty isn't outrageous - about 10 per cent. A sample sas job looks like: data; filename inf PIPE './tpipe_sl -vol aaaaaa,bbbbbb -dsn MYDATA.FILE.XXXXX 2>./errlog' LRECL=80 RECFM=F BLK=800; infile inf; input @1 var1 $; proc print; where the vsn's are 'aaaaaa' and 'bbbbbb', and the dataset name in the labels is 'MYDATA.FILE.XXXXX'. The '2>./errlog' redirects stderr - if you leave it out sas commingles stdout and stderr, which is a Bad Thing. Two caveats: -this version uses the '-fn' option of newtmr to write the drive name into ./foo, so any existing 'foo' will get zapped. This will be fixed in the next version, if this is close enough to what we want to have a next version :-) -about ascii/ebcdic: this version is just ascii. I think a real version would have to accept either ascii or ebcdic labels - presumably many std label tapes will be ebcdic. Note that I'm only talking about translating the headers, so as to find the right file. Regardless of the labels, I'll leave the ascii/ebcdic translations to sas or whoever (since to do the translations you need to know which fields are text, which are numeric, etc.). Anyway, if all the 'real world' stdlabel tapes we have use ebcdic labels, I may have to add ebcdic support right away. Let me know. ps: A version for unlabeled multi-vol tapes is almost ready, too. --------- PGP Key available at http://weber.u.washington.edu/~kenm/ 1-Apr-1996 14:03:01 -0800,27903;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Mon, 1 Apr 1996 14:03:01 -0800 (PST) Return-Path: Received: from mailer5.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA18490; Mon, 1 Apr 96 14:03:00 -0800 Received: from mx1.cac.washington.edu by mailer5.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA16458; Mon, 1 Apr 96 14:02:59 -0800 Received: from uga.cc.uga.edu by mx1.cac.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA05169; Mon, 1 Apr 96 14:02:52 -0800 Message-Id: <9604012202.AA05169@mx1.cac.washington.edu> Received: from UGA.CC.UGA.EDU by uga.cc.uga.edu (IBM VM SMTP V2R3) with BSMTP id 6911; Mon, 01 Apr 96 17:01:32 EST Received: from UGA.CC.UGA.EDU (NJE origin LISTSERV@UGA) by UGA.CC.UGA.EDU (LMail V1.2a/1.8a) with BSMTP id 0340; Mon, 1 Apr 1996 17:01:31 -0500 Date: Mon, 1 Apr 1996 16:58:36 EST Reply-To: Charles Debaun Sender: SHARE Open Computing List Comments: Resent-From: "R. Alexander" Comments: Originally-From: Charles Debaun From: "R. Alexander" Subject: POSIX Removable Media mtio Draft 4(ASCII text) To: Multiple recipients of list SHARENIX Here is a draft of the Posix tape standard. If you have comments, I suggest you join the ptape-l list or contact Chuck DeBaun at the address in the headers to this note. Richard Richard Alexander phone: (518) 276-6785 Project Manager, Server Support Services fax: (518) 276-2809 Rensselaer Polytechnic Institute Internet: alexar@rpi.edu ----------------------------Original message---------------------------- Attached is the ASCII text or the Removable media mtio working paper as of 20 January, 1996. PostScript is available in a separate mailing. Hope to see you in Jackson Hole. Chuck -------- Text file follows ----------------- SS-RM N011 01/20/96 System Services mtio Proposal IEEE P1003.1kDraft 4 Please send comments to Chuck DeBaun, debaun@fnal.fnal.gov Serial Media issues in open(), close(), read(), and write() Open(): Open() shall return -1 and set errno to EAGAIN if device is not ready, unless O_FORCE is set. Open(, O_PARTOK...) allows read of partial record without error return. Rationale:This allows both forms of existing practice while leaving the choice of behaviors to the application. If open(,O_WRONLY) or open(,O_RDWR), and medium is write protected, return -1 and set errrno to [EROFS] Device shall not be opened if in use by another session, Open() shall return -1 and set errno to EBUSY. ISSUE: Is there meaning to O_CREATE, O_TRUNC? (In the mtio world without label support, these probably have no meaning, and should probably default to O_WRONLY). However, O_TRUNC isn't really the same as O_WRONLY, even for serial media. By example from the ordinary file system, open(,O_TRUNC) followed by close() should make the file disappear. This would have the effect of terminating the medium at the beginning of the file. Is this the desired result?? If O_TRUNC defaults to O_WRONLY, close() should be able to prevent destruction of data by only terminating files which have been modified. Rationale for the session model: The session model permits the sharing of serial media amongst processes in the session. This allows, in the simplest case, a process to open a serial device and then fork a process which will open the same device, check out the medium id, position the medium, close the device and exit. Meanwhile the initial task can be going about initialization, etc. More complex scenarios might involve tasks which write, others which read what was just written and subsequently take action including repositioning the medium such that another process can overwrite the record. NOTE: It is understood that there is *NO* protection of the data by other than the processes involved if more than one process has a serial device open and at least one process is actively writing to it. The assumption is that the processes will handle the coordination. This will have to be added to the document. Probably with warnings at the danger points. Close(): If the last successful operation causing movement of the medium to the associated device modified the file without terminating it, close shall, if the _POSIX_SERIAL_AUTO_EOF pathconf variable is one, properly terminate the file and the recorded portion of the medium. If the device is defined as a no-rewind-on-close device, close() shall position the medium such that the medium can be extended without additional positioning. Session model behavior diference. In the session model, several processes may have the device open concurrently. This may require that the behavior of close be somewhat different. Perhaps even as complex as the following: If any process of a session has a serial device open for write, and the last immediately successful operation preceeding a close in any process is a write, close() shall cause proper termination of the file and the recorded portion of the medium at the position immediately following the last successful write for any process in that session. ISSUE: Does close() wait for repositioning? (This is tricky. If close() merely initiates the rewind of a rewind-on-close device, any subsequent activity before the rewind finishes will get a busy indication. On the other hand, waiting for the rewind can result in lost processing time. I would probably opt for a close initiated repositioning with a synchronization at end of process.) ISSUE: How is positioning on close specified? Device minor number? (Current practice uses the device minor number to determine the close repositioning. The device file opened determines the driver action on close. Perhaps this is one of the characteristics for which a pathconf() variable would be useful.). Another possible option is yet another flag on open(). Additional Close errnos [ERESET] Device has been irrecoverably reset. Medium has been repositioned and position information may be invalid. End of file indicators have not been written. Read(): Read(), for variable length, record structured devices and media, shall not return more than a single record. If the request is for less than a complete record and the device was not opened O_PARTOK, read() shall return -1 and set errno to [EPARTIAL]. If the device is opened O_PARTOK, a request to read less than a complete record shall return the first portion of the record and disgard the remainder leaving the medium positioned to read the next record. Read() when it encounters an end of file marker shall return zero. The position of the medium shall be just beyond the end of file indicator. Irrecoverable input errors shall leave the medium positioned as if the transmission, if any, had completed normally. That is, the medium shall be positioned after the record causing the error. If fixed length device, length must be a multiple of the physical record length. Additional Read errnos [ERESET] Device has been irrecoverably reset. Medium has been repositioned and position information may be invalid. There is some thought that this might be replaced by [EIO], however, [EIO] does not imply an additional repositioning of the medium. Write: ISSUE: What is the significance of a zero length write()? Write, for variable length, record structured devices and media, shall cause one record of the requested length to be recorded on the medium. If an output error occurs, the medium shall be positioned at the end of the information actually transferred to the medium, if any. If fixed length device, length must be a multiple of the physical record length. Write will, if length is a multiple of the physical record length, cause multiple records of the physical record length to be recorded on the medium. Write() shall return -1 and set errno to [ENOSPC] on the write() following the write() which actually caused data to be written past the logical end-of-medium. Rationale: The logical end-of-medium is a function of medium and device and is an indication that the physical end-of-medium is near. Additional write() errnos [EBADF] Medium is write protected and either O_WRONLY, O_RDWR, O_CREAT, or O_TRUNC is set in oflag. [ERESET] Medium has been irrecoverable reset. Medium has been repositioned and position information may be invalid. [ENOSPC] Set by the write() immediately following the write() causing data to be written past the logical end-of-medium. Further rationale for session model: The group examined the existng process model and found it to be too limiting. The session model allows cooperating processes to open and access a device. However, there is no statement about how access is to be coordinated. This lack of specification is intentional. The assumption is that "cooperating processes" are, by application design, coordinating. It is understood that multiple process access to serial devices is a dangerous practice. However, the process model does not prevent the inheritance of file descriptors by sub-processes which allows multiple process access. A further assumption is made that the cooperating processes shall use the proper precautions to ensure data and file integrity. Use of the appropriate open() flags is encouraged. Additional Issues: 1. Pathconf variables to be added to table 2.11. Such as: _POSIX_SERIAL_DEVICE, _POSIX_SERIAL_VBLOCK, _POSIX_SERIAL_NOREWIND_ON_CLOSE _POSIX_SERIAL_AUTO_EOF 2. Function(s) to determine the capabilities of the device. ( Some implementations provide some support of some of this functionality. ) General serial media errnos: [EAGAIN] Device not ready. [ENODEV] No devices available. [EBUSY] Device already open. [EINVAL] Invalid requests including: Attempting to read after writing, without intervening close or repositioning. Invalid parameters to functions. Attempting an operation on device which does not support it. Attempting an operation at other than beginning of medium which cam only be performed at beginning of medium(density change, recording mode change, etc.). [EIO] A general I/O error such as an irrecoverable media surface error, device unloaded after open, etc. [ENOSPC] On read() or spacing function physical end of medium or end of recorded medium is sensed. Write() attempted after logical end-of-medium. Any other commands when encountering end-of-medium or end-of-recorded-portion of medium, relative to the direction of motion. [ELENGTH] Invalid length on read() or write(). [EPARTIAL] read() determined that the length requested was less than the actual data existing in the record to be read. Section X: Serial media interfaces The contents of this section are the expansions of the mtio "ioctl" function arguments. X.1 mt_get_status - get device status information X.1.1 Synopsis int mt_get_status( filedes, struct mtget *) X.1.2 Description mt_get_status shall return tthe actual device status information in the structure mtget, defined in sys/mtio.h. The structure mtget will contain at least the following fields: short mt_type /* type of serial media device.(device id) */ short mt_dposn /* Status or position flag */ short mt_dsreg /* device specific status register*/ short mt_erreg /* device error register. (sense data) */ int mt_resid /* residual count. */ int mt_fileno /* file offset of last known position*/ int mt_blkno /*inter-record gap offset relative to beginning of mt_fileno */ /* NOTE: this will be negative if movement backwards across */ /* end-of-file indicator has occured */ unsigned short mt_flags short mt_bf /* optimal blocking factor. */ ISSUE: What is the current usage of mt_bf, how should it be interpreted? int mt_size /* Maximum record length */ ISSUE: What is the meaning of mt_size? Does it differ for fixed vs varible record device? The following constants shall be defined for mt_type: MT_ISEXABYTE /* Exabyte 8mm cartridge - SCSI */ MT_ISEXB8500 /* Exabyte 8500 8mm cart - SCSI */ The following constants shall be defined for mt_dposn; MT_EOT /*Position is physical end of medium */ MT_BOT /* Position is physical beginning of medium */ MT_WPROT /* Medium is write protected */ MT_ONL /* Device is online */ MT_EOD /* Mediium is at end of recorded portion */ MT_FMK /* Medium is at an end of file indicator */ MT_OVR /* Preceeding read() read a less than a complete record */ MT_LOST /* Position unknown */ /* For instance, movement in the backwards direction across end-of-file indication followed by write() will cause the mt_blkno to become invalid, and will set this */ The following values shall be defined in sys/mtio.h for mt_flag: MTF_SCSI MTF_REEL (Surely there are other values we can come up with for both of these) X.1.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.1.4 Errors If any of the following conditions occur, the mt_get_status() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [EINTR] The mt_get_status() function was interrupted by a signal. [EINVAL] The device is not a serial device type. The mt_get_status() function is inappropriate for this device. X.1.5 Rationale There are conditions under which a process must be able access the actual status of the device and medium. Some classes of errors in other functons may cause unpredictable positioning and status. This function provides the means to determine the necessary actions to be taken by the application. X.2 mt_space_files - position serial medium by files Purely serial media can not be expected to be seekable. The commonest structure is files separated by end-of -file indicators. File selection is accomplished by positioning from end-of-file indicator to end-fo-file indicator. This function provides this basic functionality. X.2.1. Synopsis int mt_space_file( filedes, int files) X.2.2 Description mt_space_file shall position the serial medium a number of end-of-files relative to the current position. The direction of movement shall be toward the beginning of the medium if the number of files is less than zero, and towards the end of medium if the number is greater than zero. If the number is zero. there is no movement. (Alternatively, it might be argued that, if the number of files is zero, the medium shall be positioned at the beginning of the current file.) An mt_space_file() in the backward direction which crosses an end-of-file indicator followed by any medium modification which removes, or overwirtes the end-of-file indicator with other than another end-of-file indicator, may cause mt_get_status() to return a mt_blkno which is invalid and a mt_dposn with the MT_LOST bit set to 1. If the last successful operation causing movement of the medium modified the file without terminating it: mt_space_file(), in the backward direction, shall, if the _POSIX_SERIAL_AUTO_EOF pathconf variable is set, properly terminate the file and the recorded portion of the medium before positioning. mt_space_file(), in the forward direction, shall return ENOSPC and shall not cause movement of the medium. X.2.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.2.4 Errors If any of the following errors occur, the mt_space_file() function shall return the corresponding value: : [EBADF] The filedes argument is not a valid descriptor. [EINTR] The mt_space_file() function was interrupted by a signal. [EINVAL] The filedes argument does not represent a serial device. The mt_space_record() function is invalid for this device. [ENOSPC] The mt_space_file() function encounterred the beginning-of-medium if files argument is less than zero, or end-of-recorded medium if files argument is greater than zero. X.3 mt_space_record - position serial medium by records Many files on serial media are record structured. The device is capable of detecting the divisions between records. It is therefore usually more efficient to position within a file on a serial medium by record skippng than by reading. This function provides this functionality. X.3.1. Synopsis int mt_space_record( filedes, int records) X.3.2. Description mt_space_record shall position the serial medium a number of records relative to the currrent position. The direction of movement shall be toward the beginning of medium if the number of records is less than zero, and toward the end of medium if the number is greater than zero. If the number of records is zero, the medium is not repositioned. If the last successful operation causing movement of the medium modified the file without terminating it: mt_space_record(), in the backward direction, shall properly terminate the file and the recorded portion of the medium before positioning. mt_space_record(), in the forward direction, shall return ENOSPC and shall not cause movement of the medium. If mt_space_record() encounters an end_of_file indicator while moveing in the backward direction(records variable less than zero), mt_space records() shall return [ENOSPC] and leave the medium positioned at the first record of the file containing current position position at the time the mt_space_file() was referrenced. If mt_space_records() encounters an end_of_file indicator while moving in the forward direction(records variable greater then zero), mt_space file shall return [ENOSPC] and leave the medium positioned immediately preceeding the end_file_indicator. X.3.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.3.4 Errors If any of the following errors occur, the mt_space_record() function shall return the corresponding value: : [EBADF] The filedes argument is not a valid file descriptor. [EINVAL] The filedes argument does not represent a serial device. The mt_space_record() function is invalid for this device. [EINTR] The mt_space_record() function was interrupted by a signal. [ENOSPC] The mt_space_record() function reached end-of-file if records is a value greater than zero or beginning-of-file if records is less than zero. X.4 mt_rewind - position serial medium at beginning X.4.1 Synopsis int mt_rewind(filedes) X.4.2 Description mt_rewind shall position the serial medium to the beginning of medium. If the last successful operation causing movement of the medium modified the file without terminating it, mt_rewind () shall, if the _POSIX_SERIAL_AUTO_EOF pathconf variable is set, properly terminate the file and the recorded portion of the medium. X.4.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.4.4 Errors If any of the following errors occur, the mt_rewind() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [EINVAL] The filedes argument does not represent a serial device. The mt_rewind() function is invalid for this device. [EINTR] The mt_rewind() function was interrupted by a signal. X.5. mt_weof - write end of file on serial medium X.5.1 Synopsis int mt_weof(filedes) X.5.2 Description mt_weof shall place on the serial medium at the current position that indicator which the device recognises as end- of-file and shall properly terminate the recorded portion of the medium leaving the medium positioned immediately following the end-of-file indicator. X.5.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.5.4 Errors If any of the following errors occur, the mt_weof() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. Filedes opened O_RDONLY. [EINVAL] The filedes argument does not represent a serial device. The mt_weof() function is invalid for this device. [EINTR] The mt_weof() function was interrupted by a signal. X.6. mt_space_eom - position serial to end of medium X.6.1 Synopsis int mt_space_eom(filedes) X.6.2 Description mt_space_eom shall position the serial medium to the end of the recorded portion of the medium and leave the medium positioned such that it can be extended without additional positioning. This is subject to definition of end of recorded portion of medium. This function may cause mt_get_status() return an invalid value of mt_fileno, and mt_dposn with MT_LOST bit set. X.6.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.6.4 Errors If any of the following errors occur, the mt_space_record() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [EINVAL] The filedes argument does not represent a serial device. The mt_space_eom() function is invalid for this device. [EINTR] The mt_space_eom() function was interrupted by a signal. [ENOSPC] The last operation causing movement modified the medium without terminating the file. X.7. mt_unload - unload the serial medium X.7.1 Synopsis int mt_unload(filedes) X.7.2 Description mt_unload shall cause the device to rewind and, if possible, eject the medium. The device shall at termination of this function, be not ready. X.7.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.7.4 Errors If any of the following errors occur, the mt_unload() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [EINVAL] The filedes argument does not represent a serial device. The mt_unload() function is invalid for this device. [EINTR] The mt_unload() function was interrupted by a signal. X.8 mt_reten - retension the medium X.8.1 Synopsis int mt_reten(filedes) X.8.2 Description mt_reten shall cause the device to retension the medium. This is functionally equivalent to positioning to the physical end of the medium and then rewinding. X.8.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.8.4 Errors If any of the following errors occur, the mt_reten() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [ENODEV] The filedes argument does not represent a serial device. The mt_reten() function is invalid for this device. [EINTR] The mt_reten() function was interrupted by a signal. [ENOSUP] The retension operation is not supported by this device. [EINVAL] Medium not positioned at beginning_of_medium. X.9 mt_erase - erase serial medium and rewind X.9.1 Synopsis int mt_erase(filedes) X.9.2 Description mt_erase shall cause all information recorded on the serial medium to be physically removed. The medium is than rewound. X.9.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.9.4 Errors If any of the following errors occur, the mt_erase() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. The filedes argument was opened O_RDONLY. [EINVAL] The filedes argument does not represent a serial device. The mt_erase() function is invalid for this device. Medium not positioned at beginning_of_medium. [EINTR] The mt_erase() function was interrupted by a signal. X.10 mt_back_file - position serial medium to beginning of file. X.10.1 Synopsis int mt_back_file(filedes) X.10.2 Description mt_back_file shall position the serial medium to the beginning of the file containing the current position. This position is the same as that achieved by mt_space_files(filedes, -1) followed by mt_space_files(filedes,1) if not in first file on medium. If in first file on medium mt_back_file() is equivalent to mt_rewind(). If the current position is at the beginning of a file, the medium is not repositioned. If the last successful operation causing movement of the medium modified the file without terminating it, mt_bsck_file() shall, if the _POSIX_SERIAL_AUTO_EOF pathconf variable is set, cause the proper termination of the file and the recorded portion of the medium. X.10.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.10.4 Errors If any of the following errors occur, the mt_space_record() function shall return the corresponding value: [EBADF] The filedes argument is not a valid file descriptor. [EINVAL] The filedes argument does not represent a serial device. The mt_back_file() function is invalid for this device. [EINTR] The mt_back_file() was interrupted by a signal. X.11 mt_set_mode - set or reset device recording characteristics. X.11.1 Synopsis X.11.2 Description X.11.3 Returns Upon successful completion, a value of zero shall be returned. Otherwise, a value indicative of the error shall be returned.. X.11.4 Errors If any of the following errors occur, the mt_set_mode() function shall return the corresponding value: 17-Apr-1996 13:57:51 -0700,1726;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 17 Apr 1996 13:57:51 -0700 (PDT) Return-Path: Received: from homer01.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA21446; Wed, 17 Apr 96 13:57:50 -0700 Received: from localhost by homer01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA81804; Wed, 17 Apr 96 13:57:50 -0700 Date: Wed, 17 Apr 1996 13:57:50 -0700 (PDT) From: Ken Marquess To: "James W. DeRoest" Cc: "R. Jamieson" Subject: rem tape Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Y'all may have noticed that the rem tape project is a bit stalled. To proceed, we have to finalize some of the user interface details. The note to follow will address those issues. This note concerns two interim problems - how to generate more use of the new tmr, so as to get feedback and flush out problems, and how to allow goodall tape access. Simply, why don't we install - and announce - the current newtmr on goodall, suitably labeled as 'experimental - subject to change'. While there may yet be hidden bugs (I found one just last week), we aren't going to find them on asimov, because it isn't being used with any frequency. I do think that a means/policy for recovering idle drives is required for this to work. I would just add an periodic check to the existing servers to free drives idle for more than say 1 hour. --------- PGP Key available at http://weber.u.washington.edu/~kenm/ 17-Apr-1996 14:49:56 -0700,3983;000000000011 Return-Path: Received: via tmail-4.0(2) for deroest; Wed, 17 Apr 1996 14:49:56 -0700 (PDT) Return-Path: Received: from homer01.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA17052; Wed, 17 Apr 96 14:49:56 -0700 Received: from localhost by homer01.u.washington.edu (5.65+UW96.03/UW-NDC Revision: 2.33 ) id AA14808; Wed, 17 Apr 96 14:49:55 -0700 Date: Wed, 17 Apr 1996 14:49:55 -0700 (PDT) From: Ken Marquess To: "James W. DeRoest" Cc: "R. Jamieson" Subject: rem tape 2 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This discusses the interface decisions we have to make. There are potentially minor ones - the exact names of options, etc, but only one real issue, namely whether to spawn a subshell, and recover the drive at exit, or have a simple mount command that runs and exits, thus requiring a subsequent command to free the drive. The tradeoffs of spawning, a la the current tmr, are: -you can set environment variables ($RMT) to identify the device -you get the drive back eventually, when the shell exits -you lose things like 'stty -o' when you enter the subshell (at least I do - maybe I don't have something configged right) -someone can tie up a drive for a long time after they are done if they don't exit the subshell -it's a mess to use from a batch job. It also, I think, means you have to keep the drive for the duration of a job, even if you only need it for part of the job -it can be confusing to the naive user, e.g.: tmr ... cd whatever exit pwd <--you're not where you cd'd The tradeoffs of not spawning are: -it's harder to supply the drivename. Currently newtmr -writes the name to the file of your choice (default is '.rmt') so you can do 'mt -f `cat .rmt` rewind' -writes it to stdout so you can 'TAPE1=`newtmr ...` neither of these is quite as intuitive as environment variables, IMHO -you must have a daemon reclaiming idle drives. -it's different from how we do it now -it allows you to write front ends. For example, the easiest way to get a tape file from tape to disk is the command 'tpipe mytape > disk.file', which does all the mounting and freeing for you. You can't really write that kind of application w/ the spawn approach. IMHO: The advantages offered by Nospawn (tm) for batch jobs and other use by programs are compelling enough that we should not consider an approach that does not support Nospawn. That leaves us with the question of whether to support just nospawn, or both spawn and nospawn. To my mind, there are two minor and one major advantages to continued support of spawning. The minor advantages are setting the environment vars, and freeing the drive at exit. Setting the environment vars is a plus. I don't think freeing the drive is really an issue - I think an idle-reclaim daemon will work as well. Sure, sometimes it will be idle for an hour if they forget to free the drive, but they can be idle for longer now if you just never exit the shell. I don't think either of these issues really warrants adding support for spawning. The major issue is simply that dropping spawn support would be a change, and people would have to relearn and transition. The difficulties could be minimized by an extended period of supporting both the current and new tmr. I'm tempermentally inclined to just pay that one time cost and proceed. Of course, it's easy for me to brush off the transition effort since I'm not the one who has to do it. Whatever, we need to proceed. I'll be forty soon, and want to finish this project before I retire :-) ;-) 30-Apr-1996 14:31:00 -0700,1736;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Tue, 30 Apr 1996 14:31:00 -0700 (PDT) Return-Path: Received: from mx4.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA21804; Tue, 30 Apr 96 14:30:59 -0700 Received: from red2.cac.washington.edu by mx4.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA08584; Tue, 30 Apr 96 14:30:56 -0700 Received: by red2.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA22294; Tue, 30 Apr 96 14:30:55 -0700 Date: Tue, 30 Apr 1996 14:30:52 -0700 (PDT) From: Thomas Profit To: Jim DeRoest , Douglas Luft , joe@cac.washington.edu, tduncan@u.washington.edu Cc: Sid McHarg , Sandy Moy , Craig Dayton , Mike Houlihan Subject: stk tape drives in for testing Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII STK will be able to deliver two each redwood and two each timberline drives for us to test. We should expect delivery with in the next week. Initial delivery will be at 4545 for testing followed by testing at 3737. THe compulinks scsi fast and wide channel extenders needed to operate from 4545 to 3737 is scheduled to arrive the week of the 13th of May. I expect a stk 4400 silo to arrive (and be installed at 3737) in early June. Please let me know if you for see any concerns about any of this. Tom 17-May-1996 14:14:40 -0700,2177;000000000001 Return-Path: Received: via tmail-4.0(2) for deroest; Fri, 17 May 1996 14:14:40 -0700 (PDT) Return-Path: Received: from mailer5.u.washington.edu by franklin01.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA22972; Fri, 17 May 96 14:14:39 -0700 Received: from mx1.cac.washington.edu by mailer5.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA44490; Fri, 17 May 96 14:14:39 -0700 Received: from reid.cac.washington.edu by mx1.cac.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA23155; Fri, 17 May 96 14:14:35 -0700 Received: from homer03.u.washington.edu by reid.cac.washington.edu (AIX 4.1/UCB 5.64/4.03) id AA94370; Fri, 17 May 1996 14:14:21 -0700 Received: from localhost by homer03.u.washington.edu (5.65+UW96.04/UW-NDC Revision: 2.33 ) id AA149100; Fri, 17 May 96 14:14:20 -0700 Date: Fri, 17 May 1996 14:14:19 -0700 (PDT) From: Ken Marquess To: cops-l@u.washington.edu Cc: copstaff@u.washington.edu Subject: Idle tape reclaim Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Today marks the start of a new policy that tapes idle longer than an hour will be recleimed from the user. Initially anyway, this will only be enforced on the mead drives. This is enforced by two daemons on mead1 - tmd and tmountd. I've added both to melville:/usr/local/lib/Argus/rc. What happens is that tmd periodically wakes up and asks tmountd to check the status of each drive. Tmountd will dealloc any that have been idle for more than 60 minutes, unless owned by root. Tmountd sends mail to the user also. The dealloc will fail if the drive is still opened by any processes. The hope is that that won't happen too often. The consequences are just that the user will keep the drive. In general, failures of the reclaim process or of the two daemons is not a three alarm fire - it just means you get the drive as long as you want, like you do now. --------- PGP Key available at http://weber.u.washington.edu/~kenm/