SCSI tape data loss

[Kern Sibbald]

On Mon, 2003-06-02 at 22:14, Matthew Jacob wrote:
> Probably. Actually, it was 63k.

Most of Bacula writes are 64512 bytes, and all the
data that was lost consisted of blocks of 64512 bytes.

> 
> But I sorta doubt that this was the issue.
> 
> A buddy of mine at Mirapoint did just remind me that physio can silently
> break up xfers that are even less than 64k if the buffer isn't page
> aligned- I'd forgotten about that. But I'm not sure that this is what is
> occurring.

The buffers are 64 bit aligned but not page aligned.

> 
> I need to think about this some more, but it may be that the actions
> that are being taken after EOM detection may be overwriting data. But
> don't take that to the bank at all.

Dan and I have been working on this for some time, so I'm
sure there is data loss and that it is related to the EOM.

I suspect that the problem is something very simple such as
the drive buffering data then hitting the physical EOM and
of course any buffered data goes down the bit bucket.

> 
> -matt
> 
> 
> 
> On Mon, 2 Jun 2003, Justin T. Gibbs wrote:
> 
> > >> And we have finish:
> > >>
> > >> ./tpt -v -b 5120 -r 10000000000 -n 10 -f /dev/nrsa0
> >
> > Shouldn't the test be run with the 64k record size that Bacula
> > uses?
> >
> > --
> > Justin
> >
> >