atom feed70 messages in org.freebsd.freebsd-scsiSCSI tape data loss
FromSent OnAttachments
Kern SibbaldJun 1, 2003 10:54 am 
Dan LangilleJun 1, 2003 11:32 am 
Justin T. GibbsJun 1, 2003 1:08 pm 
Kern SibbaldJun 1, 2003 2:44 pm 
Justin T. GibbsJun 1, 2003 3:39 pm 
Matthew JacobJun 1, 2003 5:00 pm 
Matthew JacobJun 1, 2003 5:13 pm 
Dan LangilleJun 1, 2003 6:58 pm 
Matthew JacobJun 1, 2003 7:03 pm 
Kern SibbaldJun 2, 2003 1:28 am 
Kern SibbaldJun 2, 2003 1:29 am 
Kern SibbaldJun 2, 2003 1:57 am 
Kern SibbaldJun 2, 2003 3:45 am 
Dan LangilleJun 2, 2003 4:28 am 
Matthew JacobJun 2, 2003 8:05 am 
Justin T. GibbsJun 2, 2003 8:10 am 
Dan LangilleJun 2, 2003 8:14 am 
Matthew JacobJun 2, 2003 8:21 am 
Kern SibbaldJun 2, 2003 8:27 am 
Dan LangilleJun 2, 2003 9:46 am 
Dan LangilleJun 2, 2003 11:05 am 
Matthew JacobJun 2, 2003 11:11 am 
Justin T. GibbsJun 2, 2003 11:49 am 
Dan LangilleJun 2, 2003 12:06 pm 
Justin T. GibbsJun 2, 2003 12:10 pm 
Matthew JacobJun 2, 2003 1:14 pm 
Dan LangilleJun 2, 2003 2:16 pm 
Matthew JacobJun 2, 2003 2:24 pm 
Kern SibbaldJun 2, 2003 2:46 pm 
Matthew JacobJun 2, 2003 2:55 pm 
Kern SibbaldJun 2, 2003 3:31 pm 
Carl ReisingerJun 2, 2003 3:44 pm 
Matthew JacobJun 2, 2003 3:44 pm 
Dan LangilleJun 2, 2003 6:37 pm 
Kern SibbaldJun 3, 2003 12:28 am 
Kern SibbaldJun 3, 2003 6:07 am 
Carl ReisingerJun 3, 2003 6:19 am 
Kern SibbaldJun 3, 2003 6:37 am 
Carl ReisingerJun 3, 2003 7:01 am 
Matthew JacobJun 3, 2003 7:34 am 
Justin T. GibbsJun 3, 2003 7:51 am 
Kern SibbaldJun 3, 2003 8:05 am 
Kern SibbaldJun 3, 2003 8:11 am 
Matthew JacobJun 3, 2003 9:03 am 
Dan LangilleJun 3, 2003 9:10 am 
Justin T. GibbsJun 3, 2003 9:24 am 
Kern SibbaldJun 3, 2003 9:40 am 
Justin T. GibbsJun 3, 2003 10:03 am 
Kern SibbaldJun 3, 2003 10:19 am 
Kern SibbaldJun 3, 2003 10:34 am 
Matthew JacobJun 3, 2003 11:00 am 
Matthew JacobJun 3, 2003 11:16 am 
Matthew JacobJun 3, 2003 11:39 am 
Justin T. GibbsJun 3, 2003 12:12 pm 
Dan LangilleJun 3, 2003 12:43 pm 
Matthew JacobJun 3, 2003 12:46 pm 
Kern SibbaldJun 3, 2003 1:05 pm 
PostMaster GeneralJun 3, 2003 2:21 pm 
Kern SibbaldJun 4, 2003 12:20 am 
Matthew JacobJun 4, 2003 7:51 am 
Kern SibbaldJun 4, 2003 9:51 am 
Kern SibbaldJun 6, 2003 7:38 am 
Dan LangilleJun 6, 2003 8:59 am 
Matthew JacobJun 6, 2003 11:50 am 
Dan LangilleJun 20, 2003 6:17 pm 
Dan LangilleJul 1, 2003 5:07 pm 
Matthew JacobJul 1, 2003 11:11 pm 
Michael L. SquiresAug 25, 2003 4:16 am 
Dan LangilleAug 25, 2003 9:13 am 
Michael L. SquiresAug 27, 2003 5:27 am 
Subject:SCSI tape data loss
From:Kern Sibbald (ke@sibbald.com)
Date:Jun 2, 2003 8:27:12 am
List:org.freebsd.freebsd-scsi

Thanks for your response.

On Mon, 2003-06-02 at 17:10, Justin T. Gibbs wrote:

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.

I'll take a look at what the residual provides and see if it corresponds to our data loss.

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.

Too bad that FreeBSD doesn't start failing writes at LEOM. That would completely remove the need for a residual and hence machine specific programming, and the cost or price for doing so is nothing.

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.

OK. Yes, performance matters but not when you are losing data. :-)