From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 14:22:07 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5496D37B401 for ; Tue, 3 Jun 2003 14:22:07 -0700 (PDT) Received: from cybernetics.com (cyborg.cybernetics.com [206.246.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BAFA43F3F for ; Tue, 3 Jun 2003 14:22:06 -0700 (PDT) (envelope-from ) Received: from martin1 ([137.157.1.143]) by cyborg.cybernetics.com with ESMTP id <119057>; Tue, 3 Jun 2003 17:20:54 -0400 Message-Id: <5.1.0.14.2.20030603170956.03195380@wheresmymailserver.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Jun 2003 17:20:24 -0400 From: PostMaster General To: freebsd-scsi@FreeBSD.org Illegal-Object: S From: Martin <> ^-expected word Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-52865B7E; boundary="=======18275876=======" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Re: SCSI tape data loss X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2003 21:22:07 -0000 --=======18275876======= Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain; x-avg-checked="avg-ok-52865B7E"; charset="us-ascii" It looks like your code is failing to detect the check condition no sense combination thrown when you hit EOT - and in variable block mode you would not see any residual on the block that crossed LEOT. I don't know enough about the FreeBSD tape driver to know where the fault lies. Even using that as a theory it did not make any sense why you were loosing so many blocks of data. I pulled up a DDS manual and checked the EOT behavior and got a surprise. Most modern tape drives automatically go into unbuffered mode past LEOT. This would insure that you would lose only one block when you hit PEOT. But the description that I have added below only states that it will throw a check condition/no sense for each write past LEOT. Thus it would seem that you have several data blocks in the buffer when PEOT is reached. I wonder if the error you are detecting as EOT is in fact a deferred error from several blocks back? Manual excerpt: The drive calculates the logical Early Warning. The Early Warning point is calculated as greater than ten megabytes before the EOT. This ensures that when Early Warning is encountered, enough space remains to successfully write any unwritten blocks up to ten megabytes. At Early Warning, the drive completes the current block transfer and terminates the command with a Check Condition, EOM bit set, and Sense Key equal to 0. If the SEW bit (in MODE SELECT Device Configuration Page) is set, the data in the buffer is then written to tape. Subsequent WRITE commands complete with a Check Condition and the EOM bit set. If writing the buffer to tape is unsuccesful because of EOT, a Volume Overflow is reported. The Residual count field in the Request Sense data reports the amount of data not transferred. Writing can continue in the Early Warning region until EOT is encountered. Any WRITE command issued within Early Warning and successfully completed, finishes with a Check Condition and the EOM bit set. If an error is encountered while writing, the Write Retry Count (in MODE SELECT Read/Write Error Recovery Page) specifies the maximum number of attempts to rewrite the data. If none of the rewrites area successful, the error is considered unrecoveralbe and reported as such. This situation may occur if the tape has severe damage. In this case, the green LED flashes rapidly. Hope this helps. Martin --=======18275876=======--