From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 11:00:37 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 5630837B404 for ; Tue, 3 Jun 2003 11:00:37 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE35C44005 for ; Tue, 3 Jun 2003 11:00:33 -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 h53I0Mqw047146; Tue, 3 Jun 2003 11:00:22 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Tue, 3 Jun 2003 11:00:21 -0700 (PDT) From: Matthew Jacob X-X-Sender: mjacob@wonky.in0.lcl To: Kern Sibbald In-Reply-To: <1054661668.13606.292.camel@rufus> Message-ID: <20030603103611.R24586@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> 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: Tue, 03 Jun 2003 18:00:37 -0000 > 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