From owner-freebsd-scsi@FreeBSD.ORG Wed Jun 4 07:51:42 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 6D60637B401 for ; Wed, 4 Jun 2003 07:51:42 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEBBA43F85 for ; Wed, 4 Jun 2003 07:51:41 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.in0.lcl (wonky.in0.lcl [172.16.166.7]) by beppo.feral.com (8.12.9/8.12.9) with ESMTP id h54EpZqw020494; Wed, 4 Jun 2003 07:51:39 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 4 Jun 2003 07:51:35 -0700 (PDT) From: Matthew Jacob X-X-Sender: mjacob@wonky.in0.lcl To: Kern Sibbald In-Reply-To: <1054711231.13606.396.camel@rufus> Message-ID: <20030604074943.E98367@wonky.in0.lcl> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <577540000.1054579840@aslan.btc.adaptec.com> <20030602131225.F71034@beppo> <1054645616.13630.161.camel@rufus> <1054653106.13606.217.camel@rufus><1054661668.13606.292.camel@rufus> <1054711231.13606.396.camel@rufus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Reply-To: mjacob@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 14:51:42 -0000 Yes, well, I have not been able to myself reproduce it. Some of the issues you brought up in the other mail have been worth all this ruckus in any case. I'll be OOT from thu-wed so I may not respond quickly or get to looking at bacula myself. I did leave a couple tape drives hooked up to one of my 4.8 boxes so I can fool around with stuff remotely if I get a chance. > Hello, > > The latest tests indicate that the sequence that I > gave you below does work. I'm going to look more > carefully at the Bacula code (the code path is > fairly complicated) because perhaps it simply > releases the drive without doing a rewind. > > I'm going to also work on simplifying the case > that we know fails (and it seems to be perfectly > reproducible). >