From owner-freebsd-scsi@FreeBSD.ORG Tue Jul 29 18:34:10 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DC6E83F for ; Tue, 29 Jul 2014 18:34:10 +0000 (UTC) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id E67A423F0 for ; Tue, 29 Jul 2014 18:34:09 +0000 (UTC) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.5/8.14.5) with ESMTP id s6TINAJ6004202; Tue, 29 Jul 2014 19:23:10 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id s6TINA3G032322; Tue, 29 Jul 2014 19:23:10 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id s6TINAad032318; Tue, 29 Jul 2014 19:23:10 +0100 Date: Tue, 29 Jul 2014 19:23:10 +0100 Message-Id: <201407291823.s6TINAad032318@higson.cam.lispworks.com> From: Martin Simmons To: Joerg Wunsch In-reply-to: <20140729090724.GA26577@uriah.heep.sax.de> (message from Joerg Wunsch on Tue, 29 Jul 2014 11:07:24 +0200) Subject: Re: Bacula fails on FreeBSD 10.x / "mt fsf" infinitely proceeds References: <20140729090724.GA26577@uriah.heep.sax.de> Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 18:34:10 -0000 >>>>> On Tue, 29 Jul 2014 11:07:24 +0200, Joerg Wunsch said: > > After finally migrating my Bacula database from SQlite into PostgreSQL > in the course of upgrading the machine to new hardware as well as from > FreeBSD 8.2 to 10-stable, Bacula now experiences strange behaviour: > > The number of files mismatch! Volume=32767 Catalog=33 > Correcting Catalog > > What happens is that Bacula, when trying to go to end of recorded > medium, issues the equivalent of > > mt fsf 32767 > > and then > > mt status > > in order to know which tape file it is located at. > > In FreeBSD 8.2, this correctly yielded the actual tape file number > (i. e., 33 in the above case), but in FreeBSD 10, it yields 32767. > You can perform "mt fsf" ad nauseum now, and each time, it pretends it > were advancing one more file ... > > I did a glance at the source code differences between 8.2 and 10.x, > but nothing sprang into my eye immediately. Does anyone have an > idea? > > Anyone out there who can test this on their machines? > > (One other change is that the machine turned from i386 into amd64 > architecture, so there's also a minor chance the problem might be > 64-bit related, although I wouldn't assume this to be the case.) Maybe you are now connecting the tape drive via a different SCSI driver? It sounds like you are running Bacula with "Fast Forward Space File = yes" in the configuration. FWIW, my latest hardware on FreeBSD 8.3 works with that, but for some reason my previous hardware on an older FreeBSD needed the traditional FreeBSD Bacula configuration described here: http://www.bacula.org/7.0.x-manuals/en/problems/Testing_Your_Tape_Drive_Wit.html#SECTION00437000000000000000 I didn't ever check why it needed that. Beware that changing the eotmodel will cause incompatibility with any existing tapes. __Martin