Bernhard R. Erdmann <[EMAIL PROTECTED]> wrote:
> How do you know the exact EOT when using hardware compression?
With DDS tape drives, you will get a CHECK CONDITION with all
data successfully written a bit before the final EOT (where you
will get a CHECK CONDITION, VOLUME OVERFLOW, where there will
be some unwritten data -- that the drive WILL report).
Assuming a proper drive, OS and mtio interface, you can safely
write until actual EOT, look at the residual bytes or blocks,
and safely determine how many bytes where written.
Alternatively, you write only till the first early warning, and
even if the tape drive/OS is in buffered mode and doesn't report
correctly residual bytes, you have about 50-100 MByte of data
till the actual EOT.
That's the theory. However, I fully agree that the above is the
ideal case: there are so many buggy OSes out there, and also
many faulty hardware. That's why it could be an option. If
that option isn't enabled, a way to do it would be to split
backups on the tape at the filemark level (a filemark flushes
the drive buffers as per SCSI specification). As soon as
EOT occurs, discard the last written file as incomplete/uncertain,
and rewrite it on the next tape.
This is exactly what Amanda does, except that Amanda does it
on a backup file level, which might well be e.g. 1 GB. Assuming
those backups could be cut in chunk of say, 100 MB, there would
be less wasted space -- at the cost of more complicated recovery.
