SCSI tape data loss

[Justin T. Gibbs]

>> > 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