Date: Mon, 2 Jun 2003 15:45:12 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Kern Sibbald <kern@sibbald.com> Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI tape data loss Message-ID: <20030602154021.T71034@beppo> In-Reply-To: <1054593075.13606.28.camel@rufus> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <577540000.1054579840@aslan.btc.adaptec.com> <20030602131225.F71034@beppo> <1054590119.13606.8.camel@rufus> <20030602145421.D71034@beppo> <1054593075.13606.28.camel@rufus>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Jun 2003, Kern Sibbald wrote: > 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. Yes, it does provide a signfier. At the end of one operation that has athe check condition that indicates early warning: } else if (sense->flags & SSD_EOM) { softc->flags |= SA_FLAG_EOM_PENDING; and SA_FLAG_ERR_PENDING = (SA_FLAG_EOM_PENDING|SA_FLAG_EIO_PENDING| SA_FLAG_EOF_PENDING), and at the start of an I/O: } else if ((softc->flags & SA_FLAG_ERR_PENDING) != 0) { .... bp->b_resid = bp->b_bcount; ... if ((softc->flags & SA_FLAG_EOM_PENDING) != 0) { /* * We now just clear errors in this case * and let the residual be the notifier. */ bp->b_error = 0; The signifier here back to the user application is a write returning less than the requested amount. > > 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. Yes. > > 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. That too. -matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030602154021.T71034>