SCSI tape data loss

[Kern Sibbald]

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. :-)