From owner-freebsd-scsi@FreeBSD.ORG Wed Jun 4 00:21:04 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 7355137B401 for ; Wed, 4 Jun 2003 00:21:04 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC15A43F3F for ; Wed, 4 Jun 2003 00:21:02 -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 h547KVv13248; Wed, 4 Jun 2003 09:20:32 +0200 From: Kern Sibbald To: mjacob@feral.com In-Reply-To: <20030603103611.R24586@wonky.in0.lcl> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <20030602110836.H71034@beppo> <20030602131225.F71034@beppo> <1054645616.13630.161.camel@rufus> <3490610000.1054651919@aslan.scsiguy.com> <20030603084701.U24586@wonky.in0.lcl> <20030603103611.R24586@wonky.in0.lcl> Content-Type: text/plain Organization: Message-Id: <1054711231.13606.396.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 09:20:31 +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: Wed, 04 Jun 2003 07:21:04 -0000 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). Best regards, Kern On Tue, 2003-06-03 at 20:00, Matthew Jacob wrote: > > There are now a lot more things making sense > > because I've had other FreeBSD users report > > "unbelievable" output from a simple test program > > I have. I'll respond below, but with the latest > > test results, the problem seems to be generated > > from the simple sequence: > > > > write() > > ... > > write() > > ioctl(MTEOF) > > ioctl(MTEOF) > > ioctl(MTREW) > > > > is there any reason why writing two end of file marks > > followed by a rewind after a series of writes should > > create data loss? > > No. That, in fact, whould flush data to the tape. Additional filemarks > should not be written even after you close here because the rewind would > clear SA_FLAG_TAPE_WRITTEN so a subsequent close won't write more. > > I'm playing around with this some as we speak. > > -matt