bparent@sdcc13.UUCP (Brian Parent) (04/17/86)
I'm having trouble with cpio going to multiple reels. It seems to write to the additional reels fine, but I have yet to successfully read the second reel. (At this point I'm assuming cpio is supposed to be able to handle multiple reels because of some vague recollection of a news article stating it could be done. Nothing in the manual page talks of this.) This is on an AT&T 3B20 system V. To write to the tape I use: find / -mtime -7 -print | cpio -ocB > /dev/rmt/0m When it says: errno: 28, Can't write output I mount the next reel and type: /dev/rmt/0m and it seems to finish its job normally. Then to read the tape for a table of contents I use: cpio -iBct < /dev/rmt/0m > file When it says: errno: 14, Can't read input I mount the next reel just as when writing. But here it begins to print out garbage into 'file' and either complains it is out of phase, try -c option, or errno 14 again (the tape is not at the end of the reel), and sometimes errno 9. If anyone has had any luck with this, or can confirm the bug, please let me know. A means of making multiple reel incremental dumps would save me a lot of headaches. Thanks in advance, Brian Parent ucbvax!sdcsvax!sdcc3!bparent
greg@ncr-sd.UUCP (Greg Noel) (04/29/86)
In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes: >I'm having trouble with cpio going to multiple reels. It seems to >write to the additional reels fine, but I have yet to successfully >read the second reel. > ..... [An extended description of the problem. He's doing it right.] Although there are some bugs in cpio having to do with multiple volumes, this isn't one of them. This particular problem happens to be brain damage in the way Unix tape drivers work, and is also one of my pet peeves, so excuse me for a moment while I dig out my soapbox. (BTW, I'll bet that you have some sort of buffered tape drive, possibly a streamer. The problem occurs on unbuffered drives, but it happens much more often on buffered drives.) The problem is this: if the tape drive asserts EOT while writing or reading a record, the driver returns an error. That's it; that's the whole problem. The actual senario goes like this: cpio writes a block that crosses the EOT marker, so it gets an error back. (Bug: cpio doesn't close the file at this point, so there aren't even any EOF marks on the end of tape, either!) Note that the block is actually written on the tape. After you have mounted the new tape, the block is written \again/ at the beginning of the new reel. (Also note that the file is closed at this point, so if you specified a no-rewind tape device, it puts the EOF markers at the \beginning/ of the new tape before it starts to write.) When you read these tapes back, you are depending upon the fact that reading the block that crosses the EOT will also get the error so that you swap tapes at exactly the same point. Well, tain't so. On unbuffered tape drives, if the EOT mark happens to be in the inter-record gap, tape drives will differ as to which which block gets the EOT indication -- it seems to be a matter of timing and I don't understand it. Sometimes it shows up as getting a duplicated block, and sometimes as a dropped block. Different brands of tape drives seem to be somewhat internally consistant, but you can't even depend upon that. On a buffered tape drive, the problem is worse, since the EOT indication is typically given several blocks \after/ the block that actually writes across the marker; on these drives, it is not possible to read back the blocks at the end, since the EOT is detected synchronously on reads. In any case, the missing or extra block(s) cause a phase error at some later point. Now, if you are considering flaming about poor hardware implementations, don't. The hardware designers have a \standard/ to abide by, and they did so. That standard doesn't say that the EOT marker has to be synchronous with the actual block that caused it, it only says that it has to happen. It is intended as a warning that the tape is nearly out; there are still (typically) several tens of feet left on the tape; that's a lot of room. Making the reporting of the EOT only semi-synchronous is a good engineering compromise. Writing after the EOT is not an error, but you need to be careful that you don't write a lot -- in fact, almost all standard-compliant implementations routinely write several blocks past the EOT (due to buffering considerations) before writing the EOV labels and switching to a new reel. No, the problem is with Unix's treatment of tape volumes. Note that as it stands, Unix cannot even read a multi-volume tape produced on, say, an IBM system -- several blocks at the end of each reel are simply inaccessible. And files produced by cpio, where the last block on the tape has no EOF after it, are difficult to read on an IBM machine, which expects one. So, what are we to do? The cure is surprising -- and surprisingly simple: make Unix comply with the standard. I don't know why it hasn't been done -- although it would break any existing multi-reel cpio volumes (as far as I know, that's about the only program that ever creates multi-volume tapes by looking for an EOT), it won't break any other existing code (or it shouldn't), and new tapes would be guaranteed to be consistant across all possible machines. It shouldn't be any problem to change, since multi-volume tapes don't seem very common -- notice the dearth of replies to this article since it was posted; there can't be many people who encounter this problem. The mods are simple: when writing a tape, if you get an EOT, backspace the record ("unwrite the record"), write a EOF marker (so you can't read it back), backspace again (in front of the EOF, so a close (or a shorter write) will work as expected), and return an error. If you look closely, this is exactly what happens if you try to write across the end of a filesystem -- if you try to cross the boundry on a write, the entire request is rejected (i.e., it is not turned into a partial write) so that if you follow with a shorter write that happens to fit, it will succeed. This actually brings the tape semantics in closer alignment with that of the disks. On a read that crosses an EOT marker, you do \nothing/. You've made sure by the change above that there should always be an EOF somewhere near the EOT, so the logic for EOF will keep you from running off the end of the tape. And now you can read industry-standard multi-reel tapes....... I don't expect that this will ever happen. Unless some statment specificly requiring this is placed in one of the Unix standards (SVID, /usr/group, or P1003 (or is it P1006? Something like that, anyway)), nobody will be motivated to actually go to the work of modifying the device drivers to fix this. And Unix will continue to be a ghetto, at least as far as tape compatibility with the rest of the world is concerned....... Are there any standards folks out there who will accept this gauntlet and prove me wrong? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
coleman@sdcsvax.UUCP (Don Coleman) (04/29/86)
In article <461@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes: >>I'm having trouble with cpio going to multiple reels. It seems to ... >The problem is this: if the tape drive asserts EOT while writing or reading >a record, the driver returns an error. That's it; that's the whole problem. ... >No, the problem is with Unix's treatment of tape volumes. Note that as it ... >The mods are simple: when writing a tape, if you get an EOT, backspace the >record ("unwrite the record"), write a EOF marker (so you can't read it back), >backspace again (in front of the EOF, so a close (or a shorter write) will >work as expected), and return an error. There are tape drives that cannot backspace(the qic-02 1/4" tape standard doesn't even contain any spacing commands), so this is not a general solution. It seems like there are two other possible solutions. The archive systems(i.e., tar and cpio) could be modified to understand that an archive may have fragmented blocks. Or, the tape drivers could be modified to understand the real nature of the EOT assertion, and continue writing out the current block, but return on error on the next block. This would of course require that enough good tape exist after the EOT mark to contain the block; I'm not familer enough with the range of tape systems to know if this is an acceptable solution. don coleman@ucsd.edu
ggs@ulysses.UUCP (Griff Smith) (04/29/86)
> In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes: > >I'm having trouble with cpio going to multiple reels. It seems to > >write to the additional reels fine, but I have yet to successfully > >read the second reel. > > ..... [An extended description of the problem. He's doing it right.] > > Although there are some bugs in cpio having to do with multiple volumes, this > isn't one of them. This particular problem happens to be brain damage in the > way Unix tape drivers work, and is also one of my pet peeves, so excuse me for > a moment while I dig out my soapbox... I second the motion. I have been doing battle inside AT&T for the last few years; it has had little (probably no) effect. > The problem is this: if the tape drive asserts EOT while writing or reading > a record, the driver returns an error. That's it; that's the whole problem. Well, not quite. The earlier Berkeley drivers (and some of the current ones) ignore the condition and let you pull the tape off the reel. > ... Note > that the block is actually written on the tape. After you have mounted the > new tape, the block is written \again/ at the beginning of the new reel. This is a system-dependent bug. The last time I checked, the VAX version of System V did it correctly; when the write fails, nothing has been written. The 3B20 version returns "out of tape" (ENOSPC) after successfully writing the block that spans the reflective strip. [deleted long description of industry standards for EOT recognition] > The mods are simple: when writing a tape, if you get an EOT, backspace the > record ("unwrite the record"), write a EOF marker (so you can't read it back), > backspace again (in front of the EOF, so a close (or a shorter write) will > work as expected), and return an error. I think this is unnecessarily heroic. The 4.3BSD TU78 driver simply sets a flag when a write sets EOT status in the controller. The next time a "write" system call is attempted, the driver returns an immediate error. I think this strategy is also used in the System V VAX tape driver. If you are paranoid that someone will remove the tape before writing a tape mark, write it and backspace over it before returning the error indication. I prefer having a "write tape mark" ioctl; it will be a no-op for a non-tape device, so you can still write device independent code. > On a read that crosses an EOT marker, you do \nothing/. You've made sure by > the change above that there should always be an EOF somewhere near the EOT, so > the logic for EOF will keep you from running off the end of the tape. And now > you can read industry-standard multi-reel tapes....... But you still can't write them. You have to have some way of overriding the EOT condition so you can write trailer labels. The 4.3BSD TU78 driver implements two ioctls: MTIOCIEOT, which causes EOT errors to be ignored, and MTIOCEEOT, which causes writes to fail with ENOSPC when writing after the reflective strip. You can then write a simple command (or function) that suppresses the error condition, jams the labels onto the tail of the tape, then enables EOT recognition again. > I don't expect that this will ever happen. Unless some statment specificly > requiring this is placed in one of the Unix standards (SVID, /usr/group, or > P1003 (or is it P1006? Something like that, anyway)), nobody will be motivated > to actually go to the work of modifying the device drivers to fix this. And > Unix will continue to be a ghetto, at least as far as tape compatibility with > the rest of the world is concerned....... Amen, brother! > Are there any standards folks out > there who will accept this gauntlet and prove me wrong? > -- > -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA And this isn't half of it. You didn't mention proper error recovery, informative error codes and program controlled tape positioning operations (back space record, skip file, back space file, rewind, etc (supported in Berkeley UNIX!)). -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
greg@ncr-sd.UUCP (Greg Noel) (04/30/86)
In article <1728@sdcsvax.UUCP> coleman@sdcsvax.UUCP (Don Coleman) writes: >There are tape drives that cannot backspace(the qic-02 1/4" tape >standard doesn't even contain any spacing commands), so this is not a >general solution. ....... the tape >drivers could be modified to understand the real nature of the EOT >assertion, and continue writing out the current block, but return on >error on the next block. S'truth, I didn't think of that. But returning error on the following block is functionally equivalent, and possibly even more optimal than the solution I proposed. It would require a slightly more complicated device driver, since the EOT state would have to be remembered, but not unreasonably so. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
jay@isis.UUCP (Jay Batson) (04/30/86)
In article <461@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes: >>I'm having trouble with cpio going to multiple reels. It seems to > ..... [An extended description of the problem. He's doing it right.] > >Although there are some bugs in cpio having to do with multiple volumes, this >isn't one of them. This particular problem happens to be brain damage in the >way Unix tape drivers work, and is also one of my pet peeves, so excuse me for >a moment while I dig out my soapbox... >... >No, the problem is with Unix's treatment of tape volumes. Note that as it >stands, Unix cannot even read a multi-volume tape produced on, say, an IBM >system -- several blocks at the end of each reel are simply inaccessible. I wondered why I seemed to get incomplete data from another outfit supplying IBM produced tapes. >And files produced by cpio, where the last block on the tape has no EOF after >it, are difficult to read on an IBM machine, which expects one. > >So, what are we to do? The cure is surprising -- and surprisingly simple: >make Unix comply with the standard. I don't know why it hasn't been done -- >although it would break any existing multi-reel cpio volumes (as far as I know, >that's about the only program that ever creates multi-volume tapes by looking >for an EOT), it won't break any other existing code (or it shouldn't), and new >tapes would be guaranteed to be consistant across all possible machines. It >shouldn't be any problem to change, since multi-volume tapes don't seem very >common -- notice the dearth of replies to this article since it was posted; >there can't be many people who encounter this problem. Maybe the dearth was because people, like me, didn't know the problem/fix. >The mods are simple:... >... >I don't expect that this will ever happen. Unless some statment specificly >requiring this is placed in one of the Unix standards (SVID, /usr/group, or >P1003 (or is it P1006? Something like that, anyway)), nobody will be motivated >to actually go to the work of modifying the device drivers to fix this. And >Unix will continue to be a ghetto, at least as far as tape compatibility with >the rest of the world is concerned....... Are there any standards folks out >there who will accept this gauntlet and prove me wrong? >-- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA I have been aggravated by lack of multi-reel/cartridge capability for quite a while - I dummy up a fix by calculating the amount of tape I've used, and simply close the tape file before I reach the EOT marker. Although I get pretty close, I waste maybe 50 - 100 feet of tape from time to time, and it forces me to incorporate this dummy-fix write routine to make any tape volumes that must be read reliably by other systems. (PS - I'm doing all this on a Systech multibus controller/Cipher 1/2" drive on an ``NCR Tower'' (Greg take note!!) Standards groups are great, but it takes more than that - it will take efforts by AT&T, UCB, and the system manufacturers who provide device drivers for systems, and who \should/ be the central source for hacking up UNIX will have to take the initiative. Greg, has NCR done it in Rel 3....? I'm going to look at incorporating your fix in the driver I wrote for my controller/tape. Yes, standards groups, take note. But more importantly, \AT&T/, \Berkley/, and others - you are the ones who need to take note. The fix seems so basic. Lets all take up Greg's "gauntlet" and "prove him wrong". ----------------------------------------------------------------------------- Jay Batson Energy Logic Systems, Inc., Denver, Colorado seismo!hao!isis!jay << preferred !isis!elsi!jay << unreliable - like me
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/30/86)
I prefer Greg's suggestion over Griff's. There seem to me to be two ways to handle magtapes on UNIX: (a) make them do the right thing to fit the generalized idea of "file"; (b) supply special magtape-handling bells and whistles. I've managed in the past to make method (a) serve quite well, even for such things as ANSI standard magtapes; since I believe in the generalized file approach, that's the method I recommend. Approach (b) is not really necessary, in my opinion. But whatever approach is used, it should be done RIGHT, which has not traditionally been the case with UNIX magtape drivers.
greg@ncr-sd.UUCP (Greg Noel) (05/01/86)
In article <1241@ulysses.UUCP> ggs@ulysses.UUCP (Griff Smith) writes: >Well, not quite. The earlier Berkeley drivers (and some of the current ones) >ignore the condition and let you pull the tape off the reel. Showing my age, I'll point out that in the V6 system I first worked on, not only did it ignore EOT, it didn't write tape marks, either. This shows that the semantics for tape drives have been evolving to be more compatible. But it hasn't gone far enough yet...... >.... The last time I checked, the VAX version >of System V did it correctly; when the write fails, nothing has been written. >The 3B20 version returns "out of tape" (ENOSPC) after successfully writing >the block that spans the reflective strip. Humpf. Last I checked, our VAX did it wrong; in fact, that's where I isolated the problem. However, the VAX is gone now, so I can't check. But notice that if this is true, it requires different actions when switching to a new volume; in one case, you must re-write the block, but not in the other. I'd like to have a \standard/ way. >........ The 4.3BSD TU78 driver simply sets >a flag when a write sets EOT status in the controller. The next time a >"write" system call is attempted, the driver returns an immediate error. Yes, this is probably a better scheme, particulary since, as was pointed out in another article, some tape drives can't backspace. >........ I prefer having a "write tape mark" ioctl; it will be a no-op >for a non-tape device, so you can still write device independent code. >........ You have to have some way of overriding >the EOT condition so you can write trailer labels. >....... You didn't mention proper error recovery, >informative error codes and program controlled tape positioning operations >(back space record, skip file, back space file, rewind, etc ..... ) Yea, verily. I didn't mention it because the specific problem was about end-of-volume handling, but indeed, the Unix tape semantics are one of the real (reel?) (sorry) dark corners. Just like the disk semantics, I would like to see the tape semantics \standardized/. It may be that not all standard-conforming systems would have all functions (like the tape drive that couldn't backspace), but if they are possible, I would like to have access to them in a standard way. Is that too much to ask? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
stone@vlad.UUCP (05/01/86)
/* Written 11:02 pm Apr 28, 1986 by coleman@sdcsvax.UUCP in vlad:net.unix */
/* ---------- "Re: need help with multi-reel cpio(" ---------- */
In article <461@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes:
>>I'm having trouble with cpio going to multiple reels. It seems to
...
>The problem is this: if the tape drive asserts EOT while writing or reading
>a record, the driver returns an error. That's it; that's the whole problem.
...
>No, the problem is with Unix's treatment of tape volumes. Note that as it
...
>The mods are simple: when writing a tape, if you get an EOT, backspace the
>record ("unwrite the record"), write a EOF marker (so you can't read it back),
>backspace again (in front of the EOF, so a close (or a shorter write) will
>work as expected), and return an error.
There are tape drives that cannot backspace(the qic-02 1/4" tape
standard doesn't even contain any spacing commands), so this is not a
general solution. It seems like there are two other possible
solutions. The archive systems(i.e., tar and cpio) could be modified to
understand that an archive may have fragmented blocks. Or, the tape
drivers could be modified to understand the real nature of the EOT
assertion, and continue writing out the current block, but return on
error on the next block. This would of course require that enough good
tape exist after the EOT mark to contain the block; I'm not familer enough
with the range of tape systems to know if this is an acceptable solution.
don
coleman@ucsd.edu
/* End of text from vlad:net.unix */ggs@ulysses.UUCP (Griff Smith) (05/03/86)
> I prefer Greg's suggestion over Griff's. There seem to me to be > two ways to handle magtapes on UNIX: (a) make them do the right > thing to fit the generalized idea of "file"; (b) supply special > magtape-handling bells and whistles. I've managed in the past > to make method (a) serve quite well, even for such things as > ANSI standard magtapes; since I believe in the generalized file > approach, that's the method I recommend. Approach (b) is not > really necessary, in my opinion. But whatever approach is used, > it should be done RIGHT, which has not traditionally been the > case with UNIX magtape drivers. I can't argue with the notion that it is better to use a "generalized file" approach". The problem is that people keep using the raw tape device while expecting it to behave like a cooked device. I think the raw interface to a device should have all the hooks necessary to control the device. In the case of a tape, that includes record and file positioning, as well as hooks to get controller status. When control functions only execute implicitly as a result of file operations, it becomes impossible to do things that don't fit the generalized file model. One of the most vexing examples for me concerns error analysis. I sometimes get tapes that have mangled blocks in them; I need to stop near a bad block and then pull it back and forth past the read heads a few times until I can decide what's wrong. The System V tape drivers insist on skipping to end of file after the error, which really gets in my way. When this happens, I usually mutter a few curses, rip the tape off the 3B20 and take it over to a TU78 on a VAX running 4.2BSD. If someone would take the time to define a tape file system using something similar to the Eighth edition generalized notion of file systems, I would be delighted. It won't happen; tapes aren't used much for anything but file backups and such refinement isn't worth it. People hardly ever use the "cooked" tape interface, even though it very nicely hides record positioning and replaces it with "lseek" support. The cooked interface might be more useful if one could have arbitrary size fixed-length blocks when using the cooked device, but that's a bit messy. I'll be happy to accumulate suggestions for how tapes should really work and pass a summary on to the UNIX support folks. I am more interested in getting better standards than in grinding my own ax. Evidence that more than two or three potential customers really care would be appreciated; the attitude now is that tape support is low priority and the current software is "good enough". -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
grr@cbmvax.cbm.UUCP (George Robbins) (05/03/86)
In article <1728@sdcsvax.UUCP> coleman@sdcsvax.UUCP (Don coleman) writes: >In article <461@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: >>In article <520@sdcc13.UUCP> bparent@sdcc13.UUCP (Brian Parent) writes: >>>I'm having trouble with cpio going to multiple reels. It seems to >... >>The problem is this: if the tape drive asserts EOT while writing or reading >>a record, the driver returns an error. That's it; that's the whole problem. >... >>No, the problem is with Unix's treatment of tape volumes. Note that as it >... >>The mods are simple: when writing a tape, if you get an EOT, backspace the >>record ("unwrite the record"), write a EOF marker (so you can't read it back), >>backspace again (in front of the EOF, so a close (or a shorter write) will >>work as expected), and return an error. > >There are tape drives that cannot backspace(the qic-02 1/4" tape >standard doesn't even contain any spacing commands)... > >don coleman@ucsd.edu I don't know about these new fangled cartridge tapes, but from my IBM system days, I seem to remember that the EOT indication from the drive was just an advisory warning that the drive had sensed the EOT marker while writing the last record. The markers are on the back of the tape, and don't affect the actual writing. Thus you could just write out your logical end of tape marker without any backup and erase foolishness. Unfortunatly, the DC300 type cartridges give you about 3" of tape before those little holes they shoot through the tape. This means that for any reasonable block size, there just isn't room to finish the block before the bits fall into the holes... Of course, if your drive does serpentine tricks, you get the warning 3 inches after you've written over the holes? I guess you are just supposed to know what size tape you are using and write the number of bits with the cheap streaming drives that don't have spacing commands. -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
rick@nyit.UUCP (Rick Ace) (05/06/86)
Doug Gwyn writes: > I prefer Greg's suggestion over Griff's. There seem to me to be > two ways to handle magtapes on UNIX: (a) make them do the right > thing to fit the generalized idea of "file"; (b) supply special > magtape-handling bells and whistles. I've managed in the past > to make method (a) serve quite well, even for such things as > ANSI standard magtapes; since I believe in the generalized file > approach, that's the method I recommend. Approach (b) is not > really necessary, in my opinion. But whatever approach is used, > it should be done RIGHT, which has not traditionally been the > case with UNIX magtape drivers. If you have method (b) only, you can simulate method (a) in user-mode code. The reverse is not necessarily true. Perhaps for your requirements, method (a) is adequate. However, those who have worked extensively with magtapes will appreciate having access to method (b) as well, particularly when trying to read a non-ANSI (or almost-ANSI) tape that was written by a non-UNIX host. All tape drives I've met support these primitive operations: Read physical record (or tape mark) and return its length Write physical record of software-specified length (before, at, and after the EOT reflector) Write tape mark (before, at, and after the EOT reflector) Rewind Detect transition into the EOT region (the tape beyond the reflector) UNIX magtape drivers should offer these functions as a bare minimum. Supporting the generalized notion of a "file" is also useful, but there are some instances where you want to tell the operating system to get out of the way and provide "hands-on" access to the tape. ----- Rick Ace Computer Graphics Laboratory New York Institute of Technology Old Westbury, NY 11568 (516) 686-7644 {decvax,seismo}!philabs!nyit!rick
greg@ncr-sd.UUCP (Greg Noel) (05/08/86)
In article <529@isis.UUCP> jay@isis.UUCP (Jay Batson) writes: >..... I dummy up a fix by calculating the amount of tape I've used, and >simply close the tape file before I reach the EOT marker. >..... I waste maybe 50 - 100 feet of tape from time to time, >and it forces me to incorporate this dummy-fix write routine to make any >tape volumes that must be read reliably by other systems. (PS - I'm doing >all this on a Systech multibus controller/Cipher 1/2" drive on an >``NCR Tower'' (Greg take note!!) Uh, I'll take note, but the Towers are done elsewhere. The close after writing some number of feet is how most Unix programs write to tape; it works most of the time, but what happens if you have a short reel? It's not handled very gracefully, as a rule...... That's why a standard, industry-compatible way of doing it would be such a blessing. >....... Greg, has NCR done it in Rel 3....? Not as far as I know. Again, the Tower development is done in Columbia, SC, and I can't speak for them. If you want it done, send in a bug report via your NCR rep. As a "real user" you probably have more leverage than do I. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
greg@ncr-sd.UUCP (Greg Noel) (05/08/86)
In article <236@nyit.UUCP> rick@nyit.UUCP (Rick Ace) writes: >Doug Gwyn writes: >> I prefer Greg's suggestion over Griff's. There seem to me to be >> two ways to handle magtapes on UNIX: (a) make them do the right >> thing to fit the generalized idea of "file"; (b) supply special >> magtape-handling bells and whistles. Hmmmmm..... I didn't know our suggestions were opposed. I was arguing for minimum semantics that were compatible with the rest of the industry. Griff and Rick are arguing that more complete semantics should be provided. The ideal probably would be to have the minimum semantics \required/ as part of the standard, but have the "bells and whistles" be present only if the actual transport was capable of it (i.e., you'd have to check the return value of the ioctl (or whatever) to be sure that your action was executed). >> ........ But whatever approach is used, >> it should be done RIGHT, which has not traditionally been the >> case with UNIX magtape drivers. Yea, verily. It would also require some careful thought to be sure that most of the operations could be simulated on transports that cannot do all of the "standard" functions. That's why I think a standard for (a) would be more likely than a standard for (b). >If you have method (b) only, you can simulate method (a) in user-mode >code. The reverse is not necessarily true. Maybe. But is is worth it? >All tape drives I've met support these primitive operations: > Read physical record (or tape mark) and return its length > Write physical record of software-specified length (before, > at, and after the EOT reflector) > Write tape mark (before, at, and after the EOT reflector) > Rewind > Detect transition into the EOT region (the tape beyond the reflector) >UNIX magtape drivers should offer these functions as a bare minimum. Yes, with the semantics that you get a write error in the EOT region, and the record is \not/ \written/. The only things that you should be permitted to do at this point are close, rewind, or possibly issue an ioctl to permit one more block to be written. (And if you do rewind without closing, the driver should ensure that EOFs are written.) >Supporting the generalized notion of a "file" is also useful, but >there are some instances where you want to tell the operating system >to get out of the way and provide "hands-on" access to the tape. I agree, but I think the one-way file semantics are the minimal set that should be provided, with the hands-on fiddling as extensions. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
abc@lpi.UUCP (Anton Chernoff) (05/13/86)
In article <478@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes: > >Yes, with the semantics that you get a write error in the EOT region, and the >record is \not/ \written/. The only things that you should be permitted to do >at this point are close, rewind, or possibly issue an ioctl to permit one more >block to be written. (And if you do rewind without closing, the driver should >ensure that EOFs are written.) > Sorry, but the standards require that you be able to write past the end of tape marker. Remember where and when magtape originated: the makers of Incredibly Big Machines. Those systems caused the standards to require that when you hit EOT, you finish writing the record you were writing (i.e., you write right over the EOT marker!) and then, as soon as possible, write standard EOT1 labels and possibly user-defined EOT labels. The physical standards for tape media required that there be enough tape past the EOT marker that you could write a full record (of some fairly large size) plus the required labels. [Note that the OS typically handled writing the labels, then prompting the operator to mount a new reel, and then writing the BOT labels that marked the tape as a continued reel.] The EOT mark is ADVISORY ONLY. It may NOT "prevent" the user from doing subsequent writes. The right thing for Unix to do (under control of cpio or tar) is the SAME THING: finish the write, write an EOT record (OK, a simple EOF might do, but I don't like the idea), close/rewind the reel, and mount a new reel. [cartridge, whatever] When reading a tape, it is perfectly valid for the hardware/software to IGNORE the physical EOT reflective mark. The software that wrote it did the right thing, and you'll detect the EOF mark and EOT records before you run out of tape. (After all, you wrote them.) If I had my copy of the ANSI standards, I could give you the exact physical requirements and the exact label record and EOF mark layouts. The point I'm making is that THERE ARE STANDARDS. The Unix world can and should follow them. -- Anton (...!{harvard,linus}!axiom!lpi!abc) "Entropy isn't what it used to be."
greg@ncr-sd.UUCP (Greg Noel) (05/20/86)
I'll be gracious and assume that the reason that you are so far off the point is that you either (a) didn't read the articles leading up to the one to which you replied, or (b) didn't understand the article to which you replied. I normally wouldn't respond to something like that, but in this case, I think it's important that people don't think that I actually meant the words you are putting in my mouth. I also want to correct some erroneous statements. The context of the discussion was that Unix EOT semantics were neither (a) internally consistant with themselves, nor (b) compatible with industry standards. The conversation had then drifted to how the Unix semantics could be modified to correct these deficiencies. In article <153@lpi.UUCP> abc@lpi.UUCP (Anton Chernoff) writes: >Sorry, but the standards require that you be able to write past the end of tape >marker. I didn't say that, and the fragement of my article you quoted strongly implied that I felt it should be possible to write past the EOT marker (with suitable restrictions). But in point of fact, the standard doesn't \require/ that it must be possible to write after the EOT marker; it just makes it \possible/ to do a limited amount of writing after the EOT marker, if desired. That's a very different thing. > ..... [Blather about how Itty Bitty Machines handles EOT, which includes > the remarkable statment ... ] >you write right over the EOT marker! This is not surprising. The EOT marker is not even on the same side of the tape as the magnetic recording surface. Read/write and detecting the EOT are completely independant operations. >The EOT mark is ADVISORY ONLY. It may NOT "prevent" the user from doing >subsequent writes. For Unix, this is just flat wrong. If you do not "prevent" the user from doing subsequent writes, how do you expect him to stop without running off the end of the reel? The issue under discussion was how to present the EOT warning to the Unix process that did the write. This has to be done in a way that is compatible with current file semantics, i.e., programs that don't know they are writing to a tape should be given an indication that they understand -- like "write error". >The right thing for Unix to do (under control of cpio or >tar) is the SAME THING: finish the write, write an EOT record .... >...... close/rewind the reel, and mount a new reel. This is \exactly/ what I said in the article to which you are replying. In fact, this is \exactly/ what I said in the portion that you quoted. > .... When reading a tape, it is perfectly valid for >the hardware/software to IGNORE the physical EOT reflective mark. The software >that wrote it did the right thing, and you'll detect the EOF mark and EOT >records before you run out of tape. (After all, you wrote them.) Again, this is \exactly/ what I said, although in a prior article. >....... The point I'm >making is that THERE ARE STANDARDS. The Unix world can and should follow them. Again, that is \exactly/ my argument. Please don't put words in my mouth that I don't mean. Now, can we get back to the discussion, already in progress, of what semantics should be specified for Unix (and clones) so that industry-standard tapes can be read and written? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA