From owner-freebsd-scsi@FreeBSD.ORG Tue Jun 3 06:07:40 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 6E31F37B404 for ; Tue, 3 Jun 2003 06:07:40 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC9B43FBF for ; Tue, 3 Jun 2003 06:07:38 -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 h53D6uv09487; Tue, 3 Jun 2003 15:06:57 +0200 From: Kern Sibbald To: mjacob@feral.com In-Reply-To: <20030602131225.F71034@beppo> References: <3EDB31AB.16420.C8964B7D@localhost> <3EDB59A4.27599.C93270FB@localhost> <20030602110836.H71034@beppo> <20030602131225.F71034@beppo> Content-Type: text/plain Organization: Message-Id: <1054645616.13630.161.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 03 Jun 2003 15:06:56 +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: Tue, 03 Jun 2003 13:07:40 -0000 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. The results were the same (more or less) 12 blocks of data were lost, which corresponds to the smaller size of the restored file that was split across two tapes. These 12 blocks were also at the end of the tape. During the restore, Bacula reported the following: 03-Jun-2003 05:01 undef-sd: RestoreFiles.2003-06-03_04.36.59 Error: Invalid block number. Expected 6060, got 6072 and in Bacula's database, Bacula indicates that blocks 0 to 6072 were written to the first tape. In fact, only blocks 0 to 6071 were written to the first tape -- I see that Bacula has included the failed block in its count, which is wrong, but this doesn't change the results at all though. Bottom line: Even when we eliminate the code that backs up and re-reads the last block, we still see the last 12 or 13 blocks being lost. They were written by the program but are not physically on the tape. Next step: Dan is now running a test where Bacula will stop writing on the first tape before the EOM is reached. Best regards, Kern