From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 17 18:36:54 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C52FBED; Tue, 17 Feb 2015 18:36:54 +0000 (UTC) Received: from mithlond.kdm.org (mithlond.kdm.org [70.56.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "A1-33714", Issuer "A1-33714" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45553E59; Tue, 17 Feb 2015 18:36:54 +0000 (UTC) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t1HIajS8031169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Feb 2015 11:36:45 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1HIajwt031168; Tue, 17 Feb 2015 11:36:45 -0700 (MST) (envelope-from ken) Date: Tue, 17 Feb 2015 11:36:45 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150217183645.GA30947@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Tue, 17 Feb 2015 11:36:46 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mithlond.kdm.org Cc: current@freebsd.org, scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:36:54 -0000 On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: > > > On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry wrote: > > > > > > I have a fairly large set of changes to the sa(4) driver and mt(1) driver > > that I'm planning to commit in the near future. > > > > A description of the changes is here and below in this message. > > > > If you have tape hardware and the inclination, I'd appreciate testing and > > feedback. > > I have a DLT 8000 and an SDLT 220. > > I don't have anything running current, but I have a spare machine which I could use for testing. > > Do you see any value is tests with that hardware? I'd be testing it via Bacula. > > disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer. > Actually, yes. Bacula is a bit tricky to configure, so your trying it out would be helpful if you have the time. In looking at the manuals for both the SDLT 220 and the DLT 8000, they both claim to support long position information for the SCSI READ POSITION command. You can see what I'm talking about by doing: mt eod mt status On my DDS-4 tape drive, this shows: # mt -f /dev/nsa3 status Drive: sa3: Serial Number: HJ00YWY --------------------------------- Mode Density Blocksize bpi Compression Current: 0x26:DDS-4 1024 bytes 97000 enabled (DCLZ) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: -1 Calc Record Number: -1 Residual: 0 Reported File Number: -1 Reported Record Number: -1 Flags: None But on an LTO-5, which will give long position information, I get: [root@doc ~]# mt status Drive: sa0: --------------------------------- Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 enabled (0x1) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 2 Calc Record Number: -1 Residual: 0 Reported File Number: 2 Reported Record Number: 32373 Flags: None That, in combination with the changes I made to the position information code in the driver, mean that even the old MTIOCGET ioctl should return an accurate file number at end of data. e.g., on the LTO-5: [root@doc ~]# mt ostatus Mode Density Blocksize bpi Compression Current: 0x58:LTO-5 variable 384607 0x1 ---------available modes--------- 0: 0x58:LTO-5 variable 384607 0x1 1: 0x58:LTO-5 variable 384607 0x1 2: 0x58:LTO-5 variable 384607 0x1 3: 0x58:LTO-5 variable 384607 0x1 --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 2 Record Number: -1 Residual Count -1 So the thing to try, in addition to just making sure that Bacula continues to work properly, is to try setting this for the tape drive in bacula-sd.conf: Hardware End of Medium = yes It looks like the Bacula tape program (btape) has a test mode, and it would be good to run through the tests on one of the tape drives and see whether they work, and whether the results are different before and after the changes. I'm not sure how to enable the test mode. > I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL. > Thanks! If there are additional features they would like out of the tape driver, I'm happy to talk about it. (Or help if they'd like to use the new status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.) Ken -- Kenneth Merry ken@FreeBSD.ORG