From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 2 14:46:53 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 8326237B401 for ; Mon, 2 Jun 2003 14:46:53 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D43F43FAF for ; Mon, 2 Jun 2003 14:46:51 -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 h52Lg0v06734; Mon, 2 Jun 2003 23:42:00 +0200 From: Kern Sibbald To: mjacob@feral.com In-Reply-To: <20030602131225.F71034@beppo> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <20030602110836.H71034@beppo> <20030602131225.F71034@beppo> Content-Type: text/plain Organization: Message-Id: <1054590119.13606.8.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 02 Jun 2003 23:41:59 +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 21:46:53 -0000 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 > > > >