| 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: | Justin T. Gibbs (gib...@scsiguy.com) | |
| Date: | Jun 2, 2003 8:10:52 am | |
| List: | org.freebsd.freebsd-scsi | |
My personal preference is for data security before performance.
There is no potential for lost data if you handle the status that is presented to you.
Could you explain that more in detail? If you mean dig into the OS/driver specific details of an MTIOCERRSTAT packet. That *shouldn't* be necessary -- at least it is not necessary on Solaris/Linux to guarantee data integrity.
If you properly honor the residual provided in MTIOCERRSTAT, then you will know what data needs to be rewritten. In otherwords, all the information required to behave correctly is there.
The tape driver doesn't have any buffering code (unlike Linux which does). The tape drive has a buffer. We are just enabling the use of that buffer. If you really want to do this simply, just do a write filemarks of 0 marks everytime you are about to switch input files. The write marks flushes the device's buffer an guarantees that any residual will be within the fd that you are currently using. This would imply that you only need to explicitly buffer if you support backups from stdin.
I don't mind if the tape drive buffers data as long as it writes *all* of that data to the tape and informs me on the next write that the LEOM logical EOM in Solaris parlance (or early EOM) has been hit.
FreeBSD does start to fail writes at LEOM, but depending on the tape type and the amount of buffer, etc. you may or may not get all data from the buffer to the tape. That is why a residual is provided.
You can never recover the round trip time on the SCSI bus unless you either have a device that allows you to queue more than one command at a time or that buffers. I believe that only FC tape devices support queuing more than one command at a time, but few programs support this anyway (unless you lie and say that a previous write has completed).
I can see that performance concerns you because you wrote the driver,
I care about performance because performance matters. I didn't write this driver.
-- Justin





