From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 2 15:31:58 2003 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4B5A37B401 for ; Mon, 2 Jun 2003 15:31:57 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF3143FA3 for ; Mon, 2 Jun 2003 15:31:56 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h52MVFv06875; Tue, 3 Jun 2003 00:31:15 +0200 From: Kern Sibbald To: mjacob@feral.com 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> Content-Type: text/plain Organization: Message-Id: <1054593075.13606.28.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 00:31:15 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org Subject: Re: SCSI tape data loss X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2003 22:31:58 -0000 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