usenet@abnjh.UUCP (usenet) (03/06/84)
I really like this one -- >> Yes, it is about time that the stupid method of dealing with end of tape >> on unix disappears. >> I have changed the drivers locally as follows >> On the write which passes the EOT mark, normal status is returned. >> i.e. the block was written out correctly. >> On any future write, EEOT is returned, and the block isn't written. >> Thus, ordinary processes which know nothing about tapes run >> correctly, and there is no problem; however since they call perror >> you get a reasonable error message when they die. >> However, for smart processes, you can do a MTIOCEOT which say's >> that you know you've hit the end of tape, but you'd like >> to write out trailer records. It then lets you do whatever you >> like; even go off the end of the tape. >> On reads, you always get the block, it ignores the end of tape; >> its up to you to verify that correct tape marks were written. >> Anyhow, with this actually fairly trivial change, you can now very >> easily change dump to correctly handle end of tape. >> I have fixes for mt.c and ut.c if anybody wants them; you can of course >> also have the fix to dump. It is backwards compatible with existing UNIX programs, and retains both the flavor of UNIX and the flavor of mainframe systems that (have to) know how to deal with tapes sensibly. I really hope that the USG folks are listening. This one is worth picking up! UNIX grew up on minis, where the attitude toward tapes was "You got a tape? Ok there's the tape drive. Go hang it yourself." But nowadays, most UNIX systems are run by comp centers, and users aren't allowed anywhere near the hardware. Now that we have solved the problem of EOT detection, can anybody think of an equally elegant hack to solve the problem of getting the operator to retrieve the tape you want from the library and put it on a drive and notify you when it is mounted, all without massive use of 'write(1)'. While I'm at it, can anybody suggest a way for me to retain exclusive use of the drive as long as my tape is mounted on it? Ideally, I would like to be able to follow the following script (or something like it): >> hang vol_ser=123456 file=mytape mode=read_write density=1600 The operator is informed to retrieve reel number 123456 from the library, and hang it on a (system specified?) drive with 1600BPI capability, and bugged about it until s/he does it. When the tape is hung (and only then) the hang command returns after verifying that the operator put the ring in (allowing read_write access) and checking the ansi VOL1 label. The filename 'mytape' in my working directory is now (?symbolicly?) linked to the appropriate /dev/rmtxx (or whatever) device and the device has read-write permissions for my userid only. Since tapes have lots of optional features (anybody ever used a seven track tape? with two possible paritys and three possible densities, and n possible ways of mapping 6 bits per frame to 8 bits per character!) the hang command would need a flock of options. Keeping track of the syntax for all those options will be a chore. >> tar xf mytape >> rewind mytape >> tar cf mytape src/* The 'rewind' command does the obvious thing. the 'tar' commands do their usual (not so obvious) things. >> unhang mytape The tape is rewound and unloaded, and the operator is informed to return it to the tape library. The filename 'mytape' is unlinked from the device and the device is returned to 'normal' modes. The *only* way to get the tape rewound with interlock is by using the 'unhang' command (or ?maybe? also an ioctl() for those who insist on doing *everything* themselves?) There should be ioctl() interfaces for the kinds of operations that are unique to tape drives, like rewind, forward/backward space to EOF mark, write EOF mark, etc. and commands that do those ioctls. Now comes the hard part -- If I log off (or the last process with file 'mytape' open exits?? - would this mean that 'hang' would have to be a shell builtin, so my login shell could keep a file descriptor open to 'mytape' -- I dunno, this is getting complicated... anyway, at least when I log off ... but what about background processes... like I said, complicated) the filename 'mytape' should be unlinked from the device and the device permissions reset to 'normal' (whatever that should be -- maybe root only?) Lots of open issues here. What does the net think? Rick Thomas ihnp4!abnjh!usenet or ihnp4!abnji!rbt
woods@hao.UUCP (Greg Woods) (03/07/84)
Regarding keeping exclusive access to a tape drive: we have a program
here that does it. It runs as three commands: "all", "deall" and "ft". The
"all" command first checks to make sure no one else has allocated the drive,
and if not, it chowns all the /dev/mt and /dev/rmt files pertaining to that
drive to you, and makes them mode 600 (then no one else can read or write
on that drive). "deall" chowns them back to root and makes them mode 000
(so that no one can read or write an unallocated drive). The "ft" command
(for Free Tape) was added later because of course some users forget to
deallocate. "ft" first checks to see if there are any free drives, and if
so, it informs you immediately. If not, it checks to see if any of the
allocated drives have not been read or written in the last 15 minutes,
and if so, deallocates it and informs you of the now-free drive.
This system has been running here since before I came here (over 3 years)
and we have never had a problem with it (except for the crappy old DEC tape
drives always breaking! :-)
GREG
--
{ucbvax!hplabs | allegra!nbires | decvax!stcvax | harpo!seismo | ihnp4!stcvax}
!hao!woodsmsc@qubix.UUCP (Mark Callow) (03/08/84)
>> hang vol_ser=123456 file=mytape mode=read_write density=1600
I have no objection to a hang command which requests an operator to
mount a tape. But let's be sensible about the infor the operator
needs. "vol_ser" smacks of big blue and doesn't really seem necessary.
The density field is completely redundant. Any halfway decent tape drive
automatically senses the density of a tape it is to read. The density
you write at is determined (in Unix) by the device you write to.
Some people must love typing.
--
From the Tardis of Mark Callow
msc@qubix.UUCP, decwrl!qubix!msc@Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!mscusenet@abnjh.UUCP (usenet) (03/09/84)
Greg Woods says: > Regarding keeping exclusive access to a tape drive: we have a program > here that does it. It runs as three commands: "all", "deall" and "ft". The > "all" command first checks to make sure no one else has allocated the drive, > and if not, it chowns all the /dev/mt and /dev/rmt files pertaining to that > drive to you, and makes them mode 600 (then no one else can read or write > on that drive). "deall" chowns them back to root and makes them mode 000 > (so that no one can read or write an unallocated drive). The "ft" command > (for Free Tape) was added later because of course some users forget to > deallocate. "ft" first checks to see if there are any free drives, and if > so, it informs you immediately. If not, it checks to see if any of the > allocated drives have not been read or written in the last 15 minutes, > and if so, deallocates it and informs you of the now-free drive. > This system has been running here since before I came here (over 3 years) > and we have never had a problem with it (except for the crappy old DEC tape > drives always breaking! :-) > I like this alot. particularly the 'ft' command. It solves the problem of freeing the drive at logout time without special kernel hacks. Moreover, it neatly finnesses all the 'open issues' associated with background processes that are still active at logout time. Rick Thomas ihnp4!abnjh!usenet or ihnp4!abnji!rbt
ron%brl-vgr@sri-unix.UUCP (03/12/84)
From: Ron Natalie <ron@brl-vgr> All the hang command needs is to be moved to the root so one can type... //hang ...
ado@elsie.UUCP (03/14/84)
>> From: Ron Natalie <ron@brl-vgr> >> >> All the hang command needs is to be moved to the root so one can type... >> >> //hang ... Or, if you have an old enough or outre enough version, put it in ANY directory, but reverse the name so one can type... gnah// ... -- UNIX is a Bell Labs trademark. -- UUCP: decvax!harpo!seismo!rlgvax!cvl!elsie!ado DDD: (301) 496-5688