jwp@uwmacc.UUCP (Jeffrey W Percival) (12/05/85)
Is it possible to create a tape with an odd number of bytes per record? When I try such an operation with write(2), I get a return code of -1 (Oh, sorry, this is 2.8BSD). When I do an identical write to a disk file, there is no problem. Do tape controllers only work in words? -- Jeff Percival ...!uwvax!uwmacc!jwp
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/05/85)
> Is it possible to create a tape with an odd number of bytes > per record? When I try such an operation with write(2), I > get a return code of -1 (Oh, sorry, this is 2.8BSD). When I > do an identical write to a disk file, there is no problem. > Do tape controllers only work in words? Actually, raw disk I/O is much worse but that's beside the point. Magtapes can be written with any number of bytes between about 14 and 2K (often up to 64K-1) per record (block). However, some brain-damaged operating systems maintain the transfer count internally as PDP-11 words, instead of bytes. On such systems, you can only request an even number of bytes. I don't know why you would get an error return instead of having your request rounded to an even number of bytes. I am also surprised if 2.8BSD really still has the old 6th Edition word counts instead of the 7th Edition byte counts. Look in the sources and see if there is a b_wcount (or some such name) which would indicate word count is being used.
ggs@ulysses.UUCP (Griff Smith) (12/05/85)
> > Is it possible to create a tape with an odd number of bytes > > per record? When I try such an operation with write(2), I > > get a return code of -1 (Oh, sorry, this is 2.8BSD). When I > > do an identical write to a disk file, there is no problem. > > Do tape controllers only work in words? > > Actually, raw disk I/O is much worse but that's beside the point. > > Magtapes can be written with any number of bytes between about > 14 and 2K (often up to 64K-1) per record (block). However, some > brain-damaged operating systems maintain the transfer count > internally as PDP-11 words, instead of bytes. On such systems, > you can only request an even number of bytes... Oh, you're talking about the System V VAX TU78 driver maybe? It doesn't give you the error return, it quitely pads to the nearest "word" so your copy tape isn't really a duplicate of the original. The 4.2BSD TU78 driver works with any byte count <= 63k. The 4.3BSD driver will also do "read-reverse" error correction for soft tape errors, recognize end of tape (finally), report hardware failures in human readable form and survive controller power failures without crashing the system or hanging the tape drives (except on 11/750, which gets "panic: cbhung" after a while). -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/06/85)
Oh, boy! Magtape driver wars! > Oh, you're talking about the System V VAX TU78 driver maybe? It > doesn't give you the error return, it quitely pads to the nearest > "word" so your copy tape isn't really a duplicate of the original. I don't have any experience with this driver but that's a bug. > The 4.2BSD TU78 driver works with any byte count <= 63k. The 4.3BSD > driver will also do "read-reverse" error correction for soft tape > errors, recognize end of tape (finally), report hardware failures in > human readable form and survive controller power failures without > crashing the system or hanging the tape drives (except on 11/750, > which gets "panic: cbhung" after a while). I hope they fix the driver so it moves to the next tape mark when closed in non-rewind mode. It's great fun to get the tail of a file overwritten because of this misdesign feature.
ggs@ulysses.UUCP (Griff Smith) (12/08/85)
> Oh, boy! Magtape driver wars! > ... [deleted for brevity] ... > I hope they fix the driver so it moves to the next tape mark when > closed in non-rewind mode. It's great fun to get the tail of a > file overwritten because of this misdesign feature. I hope they don't! This feature of the System V drivers makes it impossible to do serious tape hacking (besides, since when did UNIX systems try to protect users from their own carelessness -) ). The real flaw is with tar and cpio, both of which stop at end of data instead of reading the tape mark that should immediately follow. When the "skip to end of file on close" feature is implemented, the following things can happen: 1. Suppose I have just gotten a large multi-file distribution tape (the System V emulation package will do just fine). I have skipped to the fourth file (which took 5 minutes on the toy 25ips streamer I'm stuck with), then I want to verify that I am looking at the right file. I enter "cpio -ictB < /dev/rmt/0mn", verify that the right names are coming out, then hit break. Nothing happens; the ^%&$^&% operating system is skipping to the end of the file. I get to wait another five minutes for it to find the tape mark, then a third five minutes while I wait for the back space file to finish. If the tape drive had stopped dead in its tracks, I would have re-positioned it in about 15 seconds. 2. Worse, suppose I have just gotten 100 mbyte of critical data on a tape, and block number 100 (out of 10000) is hopelessly munged. If I am using one of the System V drivers, it will try to read the block a few times (six, for the VAX TU78 driver), then return "fatal I/O error". It also sets an internal flag that makes all subsequent attempts to read fail. I am now stuck; I can't read any of the data after the bad spot. If I close the tape file, the tape will be re-positioned. I can't even skip over the bad data with "forward space record", since System V doesn't have tape control operations. I might be able to put the unit off line, close the file, then re-enable the drive, but don't count on it. As a result of this "convenience" feature, I will have to wait a week while a request for a new copy of the tape filters through the bureaucracy. I repeat, the flaws are in cpio and tar. These commands should read until physical end of tape. If there is trash after the presumed end of file, it should be detected and reported. Of course, it would also be nice if the drivers would skip over bad blocks (after reporting the errors) and then allow subsequent successful reads. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/10/85)
> I repeat, the flaws are in cpio and tar. These commands should read until > physical end of tape. Well, they didn't have to on AT&T UNIX systems. However, I added this skip-to-EOF kludge some time ago in the versions of tar & cpio that I distribute. I don't know if that's in your version, Griff, but the change is straightforward. I find the idea of being in the middle of a tape file when I open it very yucky. I suppose this is partly a matter of personal style.
henry@utzoo.UUCP (Henry Spencer) (12/11/85)
> > Is it possible to create a tape with an odd number of bytes > > per record? When I try such an operation with write(2), I > > get a return code of -1 (Oh, sorry, this is 2.8BSD)... > > Magtapes can be written with any number of bytes between about > 14 and 2K (often up to 64K-1) per record (block). However, some > brain-damaged operating systems maintain the transfer count > internally as PDP-11 words, instead of bytes. On such systems, > you can only request an even number of bytes. I don't know why > you would get an error return instead of having your request > rounded to an even number of bytes. I am also surprised if 2.8BSD > really still has the old 6th Edition word counts instead of the > 7th Edition byte counts... The problem is historical in origin. Most pdp11 device controllers, back in the good (?) old days, did their transfers a word at a time and hence were restricted to working in even numbers of bytes. Virtually all pdp11 disks worked that way, for example. The magtape was practically the sole exception. So raw disk i/o (*not* via the file system, which hides all this) had to be an even number of bytes. The V[67] physio() routine, which copes with the details of raw i/o setup, therefore rejects odd byte counts; they are literally impossible on pdp11 disks. Unfortunately, the magtape driver also uses physio() to do its dirty work, and hence inherits the unnecessary even-counts-only restriction. I'm surprised that 2.8BSD hasn't fixed this particular mistake; it's not hard. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
marble@lownlab.UUCP (Marble Associates) (10/24/86)
Has anyone out there hacked write(1) so that it understands an ethernet? Or should I do it myself... Thanks, Marc (elvy@harvard)