Date: 03 Jun 2003 00:31:15 +0200 From: Kern Sibbald <kern@sibbald.com> To: mjacob@feral.com Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI tape data loss Message-ID: <1054593075.13606.28.camel@rufus> In-Reply-To: <20030602145421.D71034@beppo> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <20030602110836.H71034@beppo> <20030602131225.F71034@beppo> <1054590119.13606.8.camel@rufus> <20030602145421.D71034@beppo>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2003-06-02 at 23:55, Matthew Jacob wrote: > > 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. > > A question to ask then is why tape_pattern_tester stopped at LEOT but > Bacula didn't and kept going to PEOT. > > -matt This was just a thought, because you or Justin said that the driver does not fail writes at the LEOF, which means that unless you are doing something special in your tpt, it is not stopping at the LEOF. One thought that I had is: the fact that Bacula backs up at the EOM to re-read the last record could cause some problems. I've asked Dan if he will re-run the Bacula backup/restore test but with the re-read disabled. As someone said, this will give one more data point. Another interesting test would be to see if the same data loss occurs in a situation where a tape size is specified such that Bacula stops writing before the EOM on the first tape. Best regards, Kern
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1054593075.13606.28.camel>