From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 08:12:16 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 6080137B401 for ; Tue, 3 Jun 2003 08:12:16 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCE5C43FA3 for ; Tue, 3 Jun 2003 08:12:14 -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 h53FBlv10009; Tue, 3 Jun 2003 17:11:47 +0200 From: Kern Sibbald To: "Justin T. Gibbs" In-Reply-To: <3490610000.1054651919@aslan.scsiguy.com> 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> Content-Type: text/plain Organization: Message-Id: <1054653106.13606.217.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 17:11:47 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-scsi@freebsd.org cc: mjacob@feral.com 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: Tue, 03 Jun 2003 15:12:16 -0000 On Tue, 2003-06-03 at 16:51, Justin T. Gibbs wrote: > > Hello, > > > > Dan has now re-run our test of writing to two tapes. In > > this test, he told Bacula not to attempt to re-read the > > last block written, so Bacula wrote until -1 with errno=ENOSPC > > was returned, wrote two EOF marks then put up > > the next volume. > > Bacula is supposed to start the process of a tape change as soon > as the amount written is less than what you intended to write. This is exactly what it does. *Every* time the requested write size does not agree with the returned value, Bacula gives up on the tape. My last email has the code that does that. My email above was not very clear because I was telling you what happened in the particular case of loss of data (the -1 and errno=0 or errno=ENOSPC I don't know which). As noted here, Bacula *will* stop writing if the driver returns a short block (assuming my code isn't broken), but I have never seen that case on FreeBSD. > Ignoring the short write and waiting until you hit ENOSPC guarantees > you will hit PEOM, since the LEOM is only reported once. The tape > driver expects that you know what you are doing if you go on writing. The only additional writing Bacula does (unless I am missing something) is the two EOF marks.