From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 2 08:10:59 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 5969937B404 for ; Mon, 2 Jun 2003 08:10:59 -0700 (PDT) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 467B743F3F for ; Mon, 2 Jun 2003 08:10:58 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by aslan.scsiguy.com (8.12.8/8.12.8) with ESMTP id h52FAvIh028540; Mon, 2 Jun 2003 09:10:57 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Mon, 02 Jun 2003 09:10:57 -0600 From: "Justin T. Gibbs" To: Kern Sibbald Message-ID: <3177210000.1054566657@aslan.scsiguy.com> In-Reply-To: <1054544261.1578.1801.camel@rufus> References: <1054490081.1582.1685.camel@rufus> <2846020000.1054498114@aslan.scsiguy.com> <1054503429.1578.1715.camel@rufus> <1054544261.1578.1801.camel@rufus> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: 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 15:10:59 -0000 >> > My personal preference is for data security before performance. >> >> There is no potential for lost data if you handle the status that >> is presented to you. > > Could you explain that more in detail? If you mean dig into the > OS/driver specific details of an MTIOCERRSTAT packet. That *shouldn't* > be necessary -- at least it is not necessary on Solaris/Linux to > guarantee data integrity. If you properly honor the residual provided in MTIOCERRSTAT, then you will know what data needs to be rewritten. In otherwords, all the information required to behave correctly is there. >> The tape driver doesn't have any buffering code (unlike Linux which >> does). The tape drive has a buffer. We are just enabling the use >> of that buffer. If you really want to do this simply, just do a >> write filemarks of 0 marks everytime you are about to switch input >> files. The write marks flushes the device's buffer an guarantees >> that any residual will be within the fd that you are currently using. >> This would imply that you only need to explicitly buffer if you support >> backups from stdin. > > I don't mind if the tape drive buffers data as long as it writes > *all* of that data to the tape and informs me on the next write > that the LEOM logical EOM in Solaris parlance (or early EOM) > has been hit. FreeBSD does start to fail writes at LEOM, but depending on the tape type and the amount of buffer, etc. you may or may not get all data from the buffer to the tape. That is why a residual is provided. >> You can never recover the round trip time on the SCSI bus unless >> you either have a device that allows you to queue more than one >> command at a time or that buffers. I believe that only FC tape >> devices support queuing more than one command at a time, but few >> programs support this anyway (unless you lie and say that a previous >> write has completed). > > I can see that performance concerns you because you wrote the > driver, I care about performance because performance matters. I didn't write this driver. -- Justin