Date: Wed, 17 Jan 2001 14:54:52 -0700 (MST) From: Eric Lee Green <eric@estinc.com> To: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Troubles with Mammoth2 if there is a tape error Message-ID: <Pine.LNX.4.21.0101171427270.29550-100000@h23.estsatnet> In-Reply-To: <20010117190636.A28937@dcse.fee.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jan 2001, Cejka Rudolf wrote: > -- > WRITE(06). CDB: a 0 0 80 0 0 > Deferred Error: MEDIUM ERROR asc:9,0 > Track following error > -- > Do you have any idea, what to do? I'm not SCSI guru and do not > understand meaning of "deferred error". Well, first I would say that it is a bug in the firmware that you're testing -- after the first time that the tape drive attempts to write that block on tape, it should be reported as an immediate error, not as a deferred error. "Deferred error" means that the drive has already reported that the operation succeeded, and now has changed its mind. It's not unusual to have a deferred error (it's inherent in buffered tape i/o), but the drive is supposed to know for further writes that it should send an immediate error. I have no idea how FreeBSD handles the drive coming back and saying that sorry, it did not succeed, when it previously had said it did succeed. I assume that by this point in time FreeBSD has already returned a "success" status to dd and thus has no way of letting dd know there's a problem on the initial write. As for why you don't have this problem with Solaris, I assume that on the next attempt to write the tape driver checks the last sense data for that SCSI device, notices the last write failed, and decides to just give up then and there, oh joy... but the Solaris tape driver has its own faults (my office-mate is teaching me some new vocabulary as he deals with porting some software that delves deeply into tape internals, the impression I get is that the Solaris tape driver was okay for 1990... unfortunately, it's no longer 1990). As for Linux, don't even bother, this is the point at which the entire Linux SCSI layer locks up solid as a rock. Aren't tape drives lovely? For some interesting info, you might try running 'tapeinfo' out of the mtx package ( ftp://mtx.sourceforge.net/pub/mtx/mtx-1.2.11pre3.tar.gz ), please note the documentation at http://mtx.sourceforge.net . (Warning, this uses the SCSI generic interface to piddle with tape drives at the SCSI level, and interacts badly with native OS tape drivers... definitely a hacker type of tool). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0101171427270.29550-100000>