| From | Sent On | Attachments |
|---|---|---|
| Kern Sibbald | Jun 1, 2003 10:54 am | |
| Dan Langille | Jun 1, 2003 11:32 am | |
| Justin T. Gibbs | Jun 1, 2003 1:08 pm | |
| Kern Sibbald | Jun 1, 2003 2:44 pm | |
| Justin T. Gibbs | Jun 1, 2003 3:39 pm | |
| Matthew Jacob | Jun 1, 2003 5:00 pm | |
| Matthew Jacob | Jun 1, 2003 5:13 pm | |
| Dan Langille | Jun 1, 2003 6:58 pm | |
| Matthew Jacob | Jun 1, 2003 7:03 pm | |
| Kern Sibbald | Jun 2, 2003 1:28 am | |
| Kern Sibbald | Jun 2, 2003 1:29 am | |
| Kern Sibbald | Jun 2, 2003 1:57 am | |
| Kern Sibbald | Jun 2, 2003 3:45 am | |
| Dan Langille | Jun 2, 2003 4:28 am | |
| Matthew Jacob | Jun 2, 2003 8:05 am | |
| Justin T. Gibbs | Jun 2, 2003 8:10 am | |
| Dan Langille | Jun 2, 2003 8:14 am | |
| Matthew Jacob | Jun 2, 2003 8:21 am | |
| Kern Sibbald | Jun 2, 2003 8:27 am | |
| Dan Langille | Jun 2, 2003 9:46 am | |
| Dan Langille | Jun 2, 2003 11:05 am | |
| Matthew Jacob | Jun 2, 2003 11:11 am | |
| Justin T. Gibbs | Jun 2, 2003 11:49 am | |
| Dan Langille | Jun 2, 2003 12:06 pm | |
| Justin T. Gibbs | Jun 2, 2003 12:10 pm | |
| Matthew Jacob | Jun 2, 2003 1:14 pm | |
| Dan Langille | Jun 2, 2003 2:16 pm | |
| Matthew Jacob | Jun 2, 2003 2:24 pm | |
| Kern Sibbald | Jun 2, 2003 2:46 pm | |
| Matthew Jacob | Jun 2, 2003 2:55 pm | |
| Kern Sibbald | Jun 2, 2003 3:31 pm | |
| Carl Reisinger | Jun 2, 2003 3:44 pm | |
| Matthew Jacob | Jun 2, 2003 3:44 pm | |
| Dan Langille | Jun 2, 2003 6:37 pm | |
| Kern Sibbald | Jun 3, 2003 12:28 am | |
| Kern Sibbald | Jun 3, 2003 6:07 am | |
| Carl Reisinger | Jun 3, 2003 6:19 am | |
| Kern Sibbald | Jun 3, 2003 6:37 am | |
| Carl Reisinger | Jun 3, 2003 7:01 am | |
| Matthew Jacob | Jun 3, 2003 7:34 am | |
| Justin T. Gibbs | Jun 3, 2003 7:51 am | |
| Kern Sibbald | Jun 3, 2003 8:05 am | |
| Kern Sibbald | Jun 3, 2003 8:11 am | |
| Matthew Jacob | Jun 3, 2003 9:03 am | |
| Dan Langille | Jun 3, 2003 9:10 am | |
| Justin T. Gibbs | Jun 3, 2003 9:24 am | |
| Kern Sibbald | Jun 3, 2003 9:40 am | |
| Justin T. Gibbs | Jun 3, 2003 10:03 am | |
| Kern Sibbald | Jun 3, 2003 10:19 am | |
| Kern Sibbald | Jun 3, 2003 10:34 am | |
| Matthew Jacob | Jun 3, 2003 11:00 am | |
| Matthew Jacob | Jun 3, 2003 11:16 am | |
| Matthew Jacob | Jun 3, 2003 11:39 am | |
| Justin T. Gibbs | Jun 3, 2003 12:12 pm | |
| Dan Langille | Jun 3, 2003 12:43 pm | |
| Matthew Jacob | Jun 3, 2003 12:46 pm | |
| Kern Sibbald | Jun 3, 2003 1:05 pm | |
| PostMaster General | Jun 3, 2003 2:21 pm | |
| Kern Sibbald | Jun 4, 2003 12:20 am | |
| Matthew Jacob | Jun 4, 2003 7:51 am | |
| Kern Sibbald | Jun 4, 2003 9:51 am | |
| Kern Sibbald | Jun 6, 2003 7:38 am | |
| Dan Langille | Jun 6, 2003 8:59 am | |
| Matthew Jacob | Jun 6, 2003 11:50 am | |
| Dan Langille | Jun 20, 2003 6:17 pm | |
| Dan Langille | Jul 1, 2003 5:07 pm | |
| Matthew Jacob | Jul 1, 2003 11:11 pm | |
| Michael L. Squires | Aug 25, 2003 4:16 am | |
| Dan Langille | Aug 25, 2003 9:13 am | |
| Michael L. Squires | Aug 27, 2003 5:27 am |
| Subject: | SCSI tape data loss | |
|---|---|---|
| From: | PostMaster General (ma...@cybernetics.com) | |
| Date: | Jun 3, 2003 2:21:48 pm | |
| List: | org.freebsd.freebsd-scsi | |
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





