Your message dated Sat, 12 Nov 2011 11:28:09 -0700
with message-id <[email protected]>
and subject line closing
has caused the Debian Bug report #347582,
regarding intermittant bug in TAR/Kernel while writing to tape
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
347582: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347582
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
>
>
--- End Message ---
--- Begin Message ---
I'm closing this bug with no further action taken. The kernel and tar
versions it mentions are now ancient history, and while the docs have
been improved in the intervening time, some of what this bug asks for is
far outside the scope of tar in any case.
Bdale
pgpFSk930JMcS.pgp
Description: PGP signature
--- End Message ---
