Date: 02 Jun 2003 23:41:59 +0200 From: Kern Sibbald <kern@sibbald.com> To: mjacob@feral.com Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI tape data loss Message-ID: <1054590119.13606.8.camel@rufus> In-Reply-To: <20030602131225.F71034@beppo> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <20030602110836.H71034@beppo> <20030602131225.F71034@beppo>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054590119.13606.8.camel>