Package: tar Version: 0.14 Package: Kernel Version: 2.4.18-bf2.4
On Wed, Jan 11, 2006 at 08:31:41AM -0700, terr wrote: > I'm running a 2.4 kernel with sarge. I've found an intermittant bug that > seems to be triggered by the interaction of tar and the kernel while writing > to a SCSI tape (exabyte 8505) > > First off this bug happens randomly. I was writing about 4 GB to the drive > which takes about 3 hours and the bug occurs pretty much every time I tried > it but when is quite unpredictable. What happens is that an I/O error is > triggered and sense data is sometimes writting into /var/log/messages. This > error report is bogus I think. > > I used the default settings for tar. > > While the job was running - if I tried to type then the Keyboard acted up - > in all programs. Sometimes keystrokes were lost and often they were > duplicated. Typically I would be using vi in a Gnome terminal. > > When the keystrokes were mangled is again random but the frequency was high - > Ie - at least 1 in 20 keystrokes would either be lost or duplicated. > > I tried tar to the disk and it ran properly. I then used "dd" to write the > file to tape and this worked. I did this a number of times to confirm that > I/O errors were not reported. The drive worked perfectly and this was on the > same set of tape which were new tapes. (Sony's) > > > Next I tried setting the "-b ??" option in tar. I used "-b 1024". I COULD > NOT find any useful suggestions in any of the documentation and this is > itself a problem. The tar documentation seems to be 20 years old and it is > out of date. Writing 10240 byte records to a modren tape drive is just > stupid. Furthermore the documentation for tar is incorrect in its > terminalogy. What tar calls a record is really a block to "dd" and this is > standard terminology for tapes. What tar calls a block is really a record > but since unix is nit record oriented perhaps a chunk would be a useful term. > This documentation should be clarified. > > Furthermore the "mt blah setblk ??" parameter should be discussed with its > relationship to tar's "-b ??" option. It is perfectly valid to use dd to > copy a disk file to tape and tar can read this off the tape if it is done > properly. However the docs sure don't tell us anything about how to do this > and what various parameters mean. > > > Next - the "-b 1024" option works - but there is nothing to advise what it is > doing relative to the "mt blah setblk ??" option. What is actually taking > place here should be documented. > > Finally - with the "-b 1024" option set, tar performed flawlessly and > furthermore the keyboard issues clearled up. > > > -------------- > > So what we have is a cascade of issues: > > 1) tar default parameters are just stupid and are 20 years out of date. > These should be updated to reasonable values in the interest of not catching > users flat tooted with little booby traps and misleading dics. > > 2) the poorly choosen tar defaults trigger a schedualing problem probably in > the kernel. Since I am not a kernel developer and I am not a device driver > developer I am not able to track down what these timming issues are. However > they cause the keyboard driver to duplicate keystrokes and to lose > keystrokes. In addition they cause the SCSI tape driver to report transient > I/O errors. > > There are NO I/O errors with "-b 1024" set!!! > > I would suspect this might be too many interupts being generated which may > mean the drivers sometimes do not have enough time to do their jobs properly. > However - in the case of the SCSI tape driver - the problem may not surface > for hours. > > > I will be happy to attempt to re-write the tar documention and to clarify the > parametrs adn how they interact with "dd" and "mt". > > > Finally - it is not documented what these SCSI tape drives actually do wiht > the parameters adn how the layers of software between the application (tar or > dd) deal with them. I do realise this varies amoung drives. However the > software layers in general don't so perhaps we can document this so that > people have some idea what is going on and can make intelligent choices. > > But on this note - the default configuration should be intelligent. Then for > backwards compatibility we can add to the man and info pages what people may > need to do. > > Another problem is that when tar gets an I/O error it puts out stupid or > misleading or totally incorrect messages. It does not even advise people to > check the log files A for instance is that if tar runs out of tape it > doesn't tell the user it ran out of tape. It just says I/O error. Surely > tar can be trivially enhansed to put out some intelligent messages. > > I do realise this is a bigger issue that what the debian project covers. > However I am hoping this report can be forwarded to the appropriate people. > I don't know who they are at the moment. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
