From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 26 09:58:01 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 2DBE1A08; Thu, 26 Feb 2015 09:58:01 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACB1AA0E; Thu, 26 Feb 2015 09:58:00 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1Q9vvuB030369; Thu, 26 Feb 2015 10:57:57 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 854E9F77; Thu, 26 Feb 2015 10:57:56 +0100 (CET) Message-ID: <54EEEE1E.7020007@omnilan.de> Date: Thu, 26 Feb 2015 10:57:50 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) driver changes available for test References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E78B2249C957722F57BABFD" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 26 Feb 2015 10:57:57 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) 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: Thu, 26 Feb 2015 09:58:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E78B2249C957722F57BABFD Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime= ): > I have updated the patches. > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, si= nce > I committed those separately. > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) > > Rough draft commit message: > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > The patches against FreeBSD/head as of SVN revision 278975: > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278= 974: > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Ken, thank you very much for your work! Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly appreciate your work on tape support for FreeBSD! I compiled your 10-stable patchset for one machine with LTO2 and DDS5 drives, but haven't done much testing since I'll replace the adaptec (39160) because it's maxio is limited to 64k (while 53c1020 has 128k). sa(4) seems to work just fine with both drives, mt(1) showing "Reported File/Record Number" :-) No EOM tests done so far=85 I'll archive zfs streams, therefore I needed some kind of forward error correction. Probably people following this thread also have found to need this, therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197950 Perhaps someone want's to take this bug report. Thanks, -Harry --------------enig6E78B2249C957722F57BABFD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTu7iQACgkQLDqVQ9VXb8jEPgCgqYR8ygdo6bd/TKHIP+zY2Wpi Em4AnjRWCX9eScULaqyqvrnf4+K+BPb8 =EIKD -----END PGP SIGNATURE----- --------------enig6E78B2249C957722F57BABFD-- From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 26 22:42:05 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 859A11E4; Thu, 26 Feb 2015 22:42:05 +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 2719331B; Thu, 26 Feb 2015 22:42:04 +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 t1QMg2hW014159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Feb 2015 15:42:02 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1QMg2sb014158; Thu, 26 Feb 2015 15:42:02 -0700 (MST) (envelope-from ken) Date: Thu, 26 Feb 2015 15:42:02 -0700 From: "Kenneth D. Merry" To: Harald Schmalzbauer Subject: Re: sa(4) driver changes available for test Message-ID: <20150226224202.GA14015@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54EEEE1E.7020007@omnilan.de> 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]); Thu, 26 Feb 2015 15:42:03 -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: Thu, 26 Feb 2015 22:42:05 -0000 On Thu, Feb 26, 2015 at 10:57:50 +0100, Harald Schmalzbauer wrote: > Bez?glich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime): > > I have updated the patches. > > > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > > I committed those separately. > > > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > > dependencies. (One of them mav did for me, thanks!) > > > > Rough draft commit message: > > > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > > > The patches against FreeBSD/head as of SVN revision 278975: > > > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > > > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt > > Ken, > > thank you very much for your work! > Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly > appreciate your work on tape support for FreeBSD! > I compiled your 10-stable patchset for one machine with LTO2 and DDS5 > drives, but haven't done much testing since I'll replace the adaptec > (39160) because it's maxio is limited to 64k (while 53c1020 has 128k). > sa(4) seems to work just fine with both drives, mt(1) showing "Reported > File/Record Number" :-) No EOM tests done so far? I'm glad it is working well for you! You can do larger I/O sizes with the Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config file. e.g.: options MAXPHYS=(1024*1024) options DFLTPHYS=(1024*1024) If you set those values larger, you won't be able to do more than 132K with the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 segments * PAGE_SIZE.) > I'll archive zfs streams, therefore I needed some kind of forward error > correction. Probably people following this thread also have found to > need this, therefore I'd like to point to the new port misc/vdmfec > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 > Perhaps someone want's to take this bug report. That looks cool. :) I'm not a ports committer, but hopefully one of them will pick it up. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 27 19:05:19 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 2590DFD0; Fri, 27 Feb 2015 19:05:19 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A68229BD; Fri, 27 Feb 2015 19:05:15 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t1RJ5Cli046303; Fri, 27 Feb 2015 20:05:12 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 7186D30D; Fri, 27 Feb 2015 20:05:11 +0100 (CET) Message-ID: <54F0BFE1.4000000@omnilan.de> Date: Fri, 27 Feb 2015 20:05:05 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Kenneth D. Merry" Subject: Re: sa(4) driver changes available for test References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> <20150226224202.GA14015@mithlond.kdm.org> In-Reply-To: <20150226224202.GA14015@mithlond.kdm.org> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA4CCF1FDF8A51EB47916334" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 27 Feb 2015 20:05:12 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) 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: Fri, 27 Feb 2015 19:05:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA4CCF1FDF8A51EB47916334 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bez=FCglich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime= ): =85 >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 2= 78974: >>> >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt =85 > I'm glad it is working well for you! You can do larger I/O sizes with = the > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel con= fig > file. e.g.: > > options MAXPHYS=3D(1024*1024) > options DFLTPHYS=3D(1024*1024) > > If you set those values larger, you won't be able to do more than 132K = with > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33= > segments * PAGE_SIZE.) Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver limitations corresponding to systems MAX/DFLTPHYS. I thought only silicon limitations define it's value. But in order to have a best matching pre-production test-environment, I nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge= ). Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, LTO3 and DDS5) With DDS5, densitiy is reported as "unknown". If I remember correctly, you have your DDS4 reporting "DDS4"? > > therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197950 > That looks cool. :) I'm not a ports committer, but hopefully one of th= em > will pick it up. Cool it is indeed, but whether it's really usefull or not is beyond my expertise. I couldn't collect much MT experience yet. I know that LTO and similar "modern" MT technology do their own ECC (in the meaning of erasure code, mostly Reed-Solomon). What I don't know (but wanting to be best prepared for) is how arbitrary LTO drives behave, if the one (1) in 10^17 bits was detected to be uncorrectable. If it wasn't detected, the post erasure code (vdmfec in that case) would help for sure. But If the drive just cuts the output, or stops streaming at all, vdmfec was useless=85 According to excerpts of "Study of Perpendicular AME Media in a Linear Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So with DDS, _every_ single block pax(1) writes to tape needs to be internally corrected! Of course, nobody wants zfs' send output stream to DDS, it's much too slow/small, but just to mention. For archives of zfs streams, I don't feel safe relying on the tape drives' FEC, which was designed for backup solutions which do their own blocking+cheksumming, so the very seldom to expect uncorrectable read error would at worst lead to some/single unrecoverable files =96 even in case of database files most likely post-recoverable. But with one flipped bit in the zfs stream, you'd loose hundred of gigabytes, completely unrecoverable! As long as the tape keeps spitting complete blocks, even in the case when the tape knows that the output is not correct, vdmfec ought to be the holy grail :-) Going slightly more off topic: One hot candidate for beeing another holy grail, is mbuffer(1) for me. I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's no problem to stream LTO-4 native rate with a tape-transport-blocksize of 32k. Btw, besides the FIFO-buffering, I'm missing star(1) also for it's multi-volume support. tar(1) in base isn't really useful for tape buddies =96 IMHO it's hardly adequate for any purpose and I don't understand it's widespread usage=85 Most likely the absence of dump(8) fo= r zfs misleads to tar(1) ;-) Were there ever thoughts about implementing FIFO-buffering into sa(4)? We don't have mbuffer(1) in base, but I think, to complete FreeBSD's tape support, users should find all technology/tools, needed for using modern tape drives, in base. If sa(4) could provide sysctl-controlled FIFO-buffering, some base tools were a bit more apropriate for tape usage, I think. Thanks, -Harry --------------enigDA4CCF1FDF8A51EB47916334 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlTwv+YACgkQLDqVQ9VXb8iCnwCfXXu0XGD4ukaQRuDFIqD+5T9A bxwAoMehRAjJVEAx1LXBp9Z36sjRqHsf =KhWc -----END PGP SIGNATURE----- --------------enigDA4CCF1FDF8A51EB47916334-- From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 27 21:28:16 2015 Return-Path: Delivered-To: freebsd-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 0FEEB71D for ; Fri, 27 Feb 2015 21:28:16 +0000 (UTC) Received: from smtplqs-out33.aruba.it (smtplqs-out33.aruba.it [62.149.158.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3039AC6D for ; Fri, 27 Feb 2015 21:28:14 +0000 (UTC) Received: from webs2062.aruba.it ([62.149.132.72]) by smartcmd04.ad.aruba.it with bizsmtp id xZSy1p00A1ZsdvA01ZSyZp; Fri, 27 Feb 2015 22:26:59 +0100 Received: from webs2062 ([127.0.0.1]) by webs2062.aruba.it with Microsoft SMTPSVC(7.5.7601.17514); Fri, 27 Feb 2015 22:26:59 +0100 Subject: FREE, Notice to Appear in Court To: freebsd-scsi@freebsd.org Date: Fri, 27 Feb 2015 22:26:59 +0100 From: "State Court" Reply-To: "State Court" Message-ID: <07153bcb89e1d7b0ba04fc0b97db3653@webs2062.aruba.it> X-Priority: 3 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2015 21:26:59.0326 (UTC) FILETIME=[1E9351E0:01D052D4] Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Fri, 27 Feb 2015 21:28:16 -0000 Dear Free, This is to inform you to appear in the Court on the March 05 for your case hearing. Please, prepare all the documents relating to the case and bring them to Court on the specified date. Note: The case may be heard by the judge in your absence if you do not come. You can review complete details of the Court Notice in the attachment. Yours faithfully, Ronald Gonzalez, Court Secretary. From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 27 22:56:44 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 AD60C432; Fri, 27 Feb 2015 22:56:44 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6EE88E; Fri, 27 Feb 2015 22:56:44 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id D89906058 ; Fri, 27 Feb 2015 22:56:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150217183645.GA30947@mithlond.kdm.org> Date: Fri, 27 Feb 2015 17:56:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) 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: Fri, 27 Feb 2015 22:56:44 -0000 > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry wrote: >=20 > On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: >>=20 >>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry = wrote: >>>=20 >>>=20 >>> 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. >>>=20 >>> A description of the changes is here and below in this message. >>>=20 >>> If you have tape hardware and the inclination, I'd appreciate = testing and >>> feedback. >>=20 >> I have a DLT 8000 and an SDLT 220. >>=20 >> I don't have anything running current, but I have a spare machine = which I could use for testing. >>=20 >> Do you see any value is tests with that hardware? I'd be testing it = via Bacula. >>=20 >> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula = committer. >>=20 >=20 > Actually, yes. Bacula is a bit tricky to configure, so your trying it = out > would be helpful if you have the time. I have been unable to test yet. I've encountered time and hardware = issues. I may be able to try tomorrow. >=20 > 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. >=20 > You can see what I'm talking about by doing: >=20 > mt eod > mt status >=20 > On my DDS-4 tape drive, this shows: >=20 > # 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 >=20 > But on an LTO-5, which will give long position information, I get: >=20 > [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 >=20 > 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: >=20 > [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 >=20 > 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: >=20 > Hardware End of Medium =3D yes >=20 > 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. >=20 >> I'll let the other Bacula devs know about this. They deal with the = hardware. I work on PostgreSQL. >>=20 >=20 > 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.) >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 00:08:55 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 B532D479; Sat, 28 Feb 2015 00:08:55 +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 6E79AFB7; Sat, 28 Feb 2015 00:08:55 +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 t1S08kDJ035820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 17:08:46 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1S08kkt035819; Fri, 27 Feb 2015 17:08:46 -0700 (MST) (envelope-from ken) Date: Fri, 27 Feb 2015 17:08:46 -0700 From: "Kenneth D. Merry" To: Harald Schmalzbauer Subject: Re: sa(4) driver changes available for test Message-ID: <20150228000846.GA33584@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <54EEEE1E.7020007@omnilan.de> <20150226224202.GA14015@mithlond.kdm.org> <54F0BFE1.4000000@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F0BFE1.4000000@omnilan.de> 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]); Fri, 27 Feb 2015 17:08:46 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,NORMAL_HTTP_TO_IP,URIBL_BLOCKED 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: Sat, 28 Feb 2015 00:08:55 -0000 On Fri, Feb 27, 2015 at 20:05:05 +0100, Harald Schmalzbauer wrote: > Bez?glich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime): > > ? > >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > >>> > >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt > ? > > > I'm glad it is working well for you! You can do larger I/O sizes with the > > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config > > file. e.g.: > > > > options MAXPHYS=(1024*1024) > > options DFLTPHYS=(1024*1024) > > > > If you set those values larger, you won't be able to do more than 132K with > > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 > > segments * PAGE_SIZE.) > > Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver > limitations corresponding to systems MAX/DFLTPHYS. I thought only > silicon limitations define it's value. It depends on the driver. I thought that the Adaptec drivers go off of MAXPHYS (because that's what the driver author told me last week :), but in looking at the code, they actually have a hard-coded value that can be increased. You can bump AHC_MAXPHYS or AHD_MAXPHYS in aic7xxx_osm.h or aic79xx_osm.h, respectively. In order to make any difference, though, you would have to bump MAXPHYS/DFLTPHYS (so the sa(4) driver will use that value) or change the ahc(4)/ahd(4) driver to set the maxio field in the path inquiry CCB. > But in order to have a best matching pre-production test-environment, I > nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on > PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, > which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge). Okay. That should work. > Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, > LTO3 and DDS5) > With DDS5, densitiy is reported as "unknown". If I remember correctly, > you have your DDS4 reporting "DDS4"? That means that we need to add DDS5 to the density table in libmt. Can you send the output of 'mt status -v'? It would actually be helpful for all three drives. Also, do any of your drives give a full report for 'mt getdensity'? If so, can you send that as well? (By full report, I mean more than one line.) We don't have density codes for DDS-5/DAT 72, DAT 160 or DAT 320 yet. It looks like DDS-5 should be 0x47. > > > therefore I'd like to point to the new port misc/vdmfec > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 > > That looks cool. :) I'm not a ports committer, but hopefully one of them > > will pick it up. > > Cool it is indeed, but whether it's really usefull or not is beyond my > expertise. I couldn't collect much MT experience yet. > I know that LTO and similar "modern" MT technology do their own ECC (in > the meaning of erasure code, mostly Reed-Solomon). > What I don't know (but wanting to be best prepared for) is how arbitrary > LTO drives behave, if the one (1) in 10^17 bits was detected to be > uncorrectable. > If it wasn't detected, the post erasure code (vdmfec in that case) would > help for sure. > But If the drive just cuts the output, or stops streaming at all, vdmfec > was useless? There is a difference in the uncorrectable bit error rate and the undetectable bit error rate. The uncorrectable bit error rate for LTO-6 is 1 in 10^17. It is 1 in 10^19 for Oracle T10000 C/D drives, and 1 in 10^20 for IBM TS1150. Seagate Enterprise drives claim to have an uncorrectable bit error rate of 1 sector per 10^15 bits read. See: http://www.oracle.com/us/products/servers-storage/storage/tape-storage/t10000c-reliability-wp-409919.pdf http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=2513 http://www.seagate.com/www-content/product-content/enterprise-hdd-fam/enterprise-capacity-3-5-hdd/constellation-es-4/en-us/docs/enterprise-capacity-3-5-hdd-ds1791-8-1410us.pdf The second white paper claims that tape has an undetectable bit error rate of 1 in 1.6x10^33 bits. I assume it is referring to TS1150, but I don't know for sure. It is far more likely that your tape or tape drive will break than it is that you would get a bad bit back from the drive. > According to excerpts of "Study of Perpendicular AME Media in a Linear > Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS > has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So > with DDS, _every_ single block pax(1) writes to tape needs to be > internally corrected! Of course, nobody wants zfs' send output stream to > DDS, it's much too slow/small, but just to mention. > > For archives of zfs streams, I don't feel safe relying on the tape > drives' FEC, which was designed for backup solutions which do their own > blocking+cheksumming, so the very seldom to expect uncorrectable read > error would at worst lead to some/single unrecoverable files ? even in > case of database files most likely post-recoverable. > But with one flipped bit in the zfs stream, you'd loose hundred of > gigabytes, completely unrecoverable! > As long as the tape keeps spitting complete blocks, even in the case > when the tape knows that the output is not correct, vdmfec ought to be > the holy grail :-) A tape drive or hard drive isn't going to return bits that it knows aren't correct. They'll return an error instead. The bit error rate of a tape drive is lower than the bit error rate for a hard drive, so you're less likely to get bad bits back from a tape drive than a disk drive. Another thing you have to consider, if you're concerned about the bit error rates, is the error rate of the link that you're using to connect to the tape or disk drive. The tape/disk might read the block correctly, but you could also get corruption on the link. This article talks about disk/tape bit error rates and the link bit error rates. I haven't read the whole thing, but it should make for some interesting reading: http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-1.html With ZFS, you get protection from link and disk errors via its checksums and RAID. If there is a checksum error on one drive, it can rebuild the corrupted data using the parity/mirror information. If you want to do the same thing with a tape drive, you would need to write your data to two tapes, or have another copy somewhere that you could use as your recovery copy in case of corruption. FWIW, the sa(4) driver now supports protection information on a per-block basis. LTO (at least newer drives) and TS drives support adding a CRC on the end of each tape block written to and read from the drive. The drive will verify it on writes, and supply the checksum on reads. You could also do your own FEC scheme. > Going slightly more off topic: > One hot candidate for beeing another holy grail, is mbuffer(1) for me. > > I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but > for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge > block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's > no problem to stream LTO-4 native rate with a tape-transport-blocksize > of 32k. > Btw, besides the FIFO-buffering, I'm missing star(1) also for it's > multi-volume support. tar(1) in base isn't really useful for tape > buddies ? IMHO it's hardly adequate for any purpose and I don't > understand it's widespread usage? Most likely the absence of dump(8) for > zfs misleads to tar(1) ;-) > > Were there ever thoughts about implementing FIFO-buffering into sa(4)? > We don't have mbuffer(1) in base, but I think, to complete FreeBSD's > tape support, users should find all technology/tools, needed for using > modern tape drives, in base. If sa(4) could provide sysctl-controlled > FIFO-buffering, some base tools were a bit more apropriate for tape > usage, I think. It would probably be easier and better to just put mbuffer in the base. The challenge with doing buffering in the tape driver is that the userland application would need to use a different API to write to the driver. The standard write(2) API requires that it return status when the block is written. So if we're going to buffer up a bunch of I/O in the tape driver, we would need to do it with an async I/O type interface so that we could return an individual error status for any I/O that fails. If you're not able to stream to a tape drive with ZFS send, but it does work with mbuffer, then the issue is just an inconsistent output rate from ZFS send. mbuffer overcomes the consistency problem with buffering. We could do the buffering in the kernel, but that would mean rewriting any userland application that wants to talk to the tape drive. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 06:49:03 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CA4DDE2; Sat, 28 Feb 2015 06:49:03 +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 200F9C90; Sat, 28 Feb 2015 06:48:58 +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 t1S6m8l0040338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Feb 2015 23:48:08 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1S6lurr040337; Fri, 27 Feb 2015 23:47:56 -0700 (MST) (envelope-from ken) Date: Fri, 27 Feb 2015 23:47:56 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150228064756.GA40281@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@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]); Fri, 27 Feb 2015 23:48:08 -0700 (MST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,URIBL_BLOCKED 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: Sat, 28 Feb 2015 06:49:03 -0000 On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: > > > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry wrote: > > > > 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. > > I have been unable to test yet. I've encountered time and hardware issues. I know how that goes! (On both counts.) > I may be able to try tomorrow. So I have tested building it and it does build at least. If you're able to figure out some of the answers below, that would be great! > > > > 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 > > ? > Dan Langille > http://langille.org/ > > > > > Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 08:32:14 2015 Return-Path: Delivered-To: freebsd-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 A271D922 for ; Sat, 28 Feb 2015 08:32:14 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AECB7A9 for ; Sat, 28 Feb 2015 08:32:14 +0000 (UTC) Received: by igdh15 with SMTP id h15so6233704igd.3 for ; Sat, 28 Feb 2015 00:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=niksG2L4MMatCl0FPY5xg5wHtwDRrvA688RF/+y6t2Q=; b=N57dOou8vj01CBgegk/pfpyBM4VgByaPWTkk843MwJQvDTr46e9kQ0nJcaVNwGOmpV reOvgJzPhmzZMaUILL3dbB87l0ZZRjpoaRb9mXDs3G5lRQUIIIU6alruFCn6zxo3i9Dh eGiO7akYewqvq/cTvedanayxK5o+w9/kCvIlI0n94R5+SRLXlSIMnsozjjEpXTe4ly0v LAfKG+m0LE9dLpIGOEgtufTQdp82bbQf5P8s1MK5g8fYgVR0BesMlU+fqbIHxvVAoNaZ ha7GiCyU2oiKItNabYtXCPLErhPZU+X4BUmnrnI3Ei2qajhYrk0TKkDR70XAQQydGEFk YYbQ== MIME-Version: 1.0 X-Received: by 10.107.17.89 with SMTP id z86mr24398774ioi.52.1425112333577; Sat, 28 Feb 2015 00:32:13 -0800 (PST) Received: by 10.36.23.133 with HTTP; Sat, 28 Feb 2015 00:32:13 -0800 (PST) Date: Sat, 28 Feb 2015 16:32:13 +0800 Message-ID: Subject: What does the error code 82 mean? From: fengyd To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Sat, 28 Feb 2015 08:32:14 -0000 Hi, INQUIRY command is sent to the target, but error code 82 is returned. I added some log in the driver: SIR_COMPLETE_ERROR (pass0:sym0:0:0:0): sym_complete_error status = 18 (pass0:sym0:0:0:0): status = 82 Do you know what does the error code 82 mean? Thanks in advance. Br. Yafeng From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 08:50:52 2015 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 868C7B0F for ; Sat, 28 Feb 2015 08:50:52 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6378B2 for ; Sat, 28 Feb 2015 08:50:52 +0000 (UTC) Received: by iecvy18 with SMTP id vy18so36631584iec.13 for ; Sat, 28 Feb 2015 00:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=u2XWUWIQIj6xdkVL1rVhamb9cRCpW7C0SylPDPz4a+Q=; b=rxC58pQYyPLhlnUi3aEIxuoo7vp+Nm9ZCmkJ68ZJ///Gy1P8lnWMi6Gxgu43Sx4AzV Cf8nvByIRZHbxfB3+v2Gpb+cwyHKPMKQFsj3QixUfv0uOUxKQ3ZZBdoGS7T6ktQZuVqs IFijzHRwUCwGJL3S3SSPyO/w/c+08mTIFKROqUgaM3jdyscY+9ijT70NpJz8ty6gnLof 2DvhKJ2LqxfiLAKPxgjD7dzMin8crPIrWciMoev+50pQM8rS+ZYr7Cwk/+p4hlaDfIvD GaYZoS6jOX5i6cNGqOU5vSeeolm+xprKyubeuROd+PO83yn4VSPB5PshErqA5Mujv/H8 pmSA== MIME-Version: 1.0 X-Received: by 10.50.43.130 with SMTP id w2mr9662496igl.30.1425113451678; Sat, 28 Feb 2015 00:50:51 -0800 (PST) Received: by 10.36.23.133 with HTTP; Sat, 28 Feb 2015 00:50:51 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2015 16:50:51 +0800 Message-ID: Subject: Re: What does the error code 82 mean? From: fengyd To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Sat, 28 Feb 2015 08:50:52 -0000 Hi, It seems the error code 82 & 3F is 0x12. And the definition of the error code in the file cam.h: CAM_AUTOSENSE_FAIL = 0x10,/* Autosense: request sense cmd fail */ CAM_NO_HBA, /* No HBA Detected error */ CAM_DATA_RUN_ERR, /* Data Overrun error */ So, it means data overrun error? Thanks. Br. Yafeng On Sat, Feb 28, 2015 at 4:32 PM, fengyd wrote: > Hi, > > INQUIRY command is sent to the target, but error code 82 is returned. > I added some log in the driver: > SIR_COMPLETE_ERROR > (pass0:sym0:0:0:0): sym_complete_error status = 18 > (pass0:sym0:0:0:0): status = 82 > > Do you know what does the error code 82 mean? > > Thanks in advance. > > Br. > Yafeng > From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 15:53:21 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 8B76E386; Sat, 28 Feb 2015 15:53:21 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FDCF400; Sat, 28 Feb 2015 15:53:20 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id EA2946F06 ; Sat, 28 Feb 2015 15:53:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150228064756.GA40281@mithlond.kdm.org> Date: Sat, 28 Feb 2015 10:53:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <36E25B53-8D76-4409-87FD-5E0369A4A513@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> <20150228064756.GA40281@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) 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: Sat, 28 Feb 2015 15:53:21 -0000 > On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry wrote: >=20 > On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote: >>=20 >>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote: >>>>=20 >>>>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> A description of the changes is here and below in this message. >>>>>=20 >>>>> If you have tape hardware and the inclination, I'd appreciate = testing and >>>>> feedback. >>>>=20 >>>> I have a DLT 8000 and an SDLT 220. >>>>=20 >>>> I don't have anything running current, but I have a spare machine = which I could use for testing. >>>>=20 >>>> Do you see any value is tests with that hardware? I'd be testing it = via Bacula. >>>>=20 >>>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula = committer. >>>>=20 >>>=20 >>> Actually, yes. Bacula is a bit tricky to configure, so your trying = it out >>> would be helpful if you have the time. >>=20 >> I have been unable to test yet. I've encountered time and hardware = issues. >=20 > I know how that goes! (On both counts.) Hardware issues fixed. Now upgrading that zfsroot box from 9.2 to 10.1 = RELEASE. sudo freebsd-update -r 10.1-RELEASE upgrade Then I'll grab sources, apply your 10 STABLE patches, and build world. >=20 >> I may be able to try tomorrow. >=20 > So I have tested building it and it does build at least. If you're = able to > figure out some of the answers below, that would be great! >=20 >>>=20 >>> 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. >>>=20 >>> You can see what I'm talking about by doing: >>>=20 >>> mt eod >>> mt status >>>=20 >>> On my DDS-4 tape drive, this shows: >>>=20 >>> # 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 >>>=20 >>> But on an LTO-5, which will give long position information, I get: >>>=20 >>> [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 >>>=20 >>> 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: >>>=20 >>> [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 >>>=20 >>> 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: >>>=20 >>> Hardware End of Medium =3D yes >>>=20 >>> 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. >>>=20 >>>> I'll let the other Bacula devs know about this. They deal with the = hardware. I work on PostgreSQL. >>>>=20 >>>=20 >>> 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.) >>>=20 >>> Ken >>> --=20 >>> Kenneth Merry >>> ken@FreeBSD.ORG >>=20 >> ?=20 >> Dan Langille >> http://langille.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 16:48:04 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F09E42B; Sat, 28 Feb 2015 16:48:04 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E93E9CAA; Sat, 28 Feb 2015 16:48:03 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 1A0636FA9 ; Sat, 28 Feb 2015 16:48:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> Date: Sat, 28 Feb 2015 11:48:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) 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: Sat, 28 Feb 2015 16:48:04 -0000 > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >=20 >=20 > I have updated the patches. >=20 > I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since > I committed those separately. >=20 > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) >=20 > Rough draft commit message: >=20 > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >=20 > The patches against FreeBSD/head as of SVN revision 278975: >=20 > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt >=20 > And (untested) patches against FreeBSD stable/10 as of SVN revision = 278974: >=20 > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Not sure what I've done wrong here. I've applied your patches and run make buildworld against: [root@cuppy:/usr/src] # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/stable/10 Relative URL: ^/stable/10 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 278721 Node Kind: directory Schedule: normal Last Changed Author: ngie Last Changed Rev: 278721 Last Changed Date: 2015-02-13 21:46:22 +0000 (Fri, 13 Feb 2015) But I get: rm -f .depend GPATH GRTAGS GSYMS GTAGS =3D=3D=3D> lib/libmp (cleandir) rm -f Version.map libmp.3.gz libmp.3.cat.gz rm -f a.out mpasbn.o mpasbn.o.tmp=20 rm -f mpasbn.po mpasbn.po.tmp rm -f mpasbn.So mpasbn.so mpasbn.So.tmp rm -f libmp.so rm -f libmp.a libmp_p.a libmp.so.7 rm -f Version.map rm -f .depend GPATH GRTAGS GSYMS GTAGS =3D=3D=3D> lib/libmt (cleandir) cd: /usr/src/lib/libmt: No such file or directory *** Error code 2 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src >=20 > Thanks, >=20 > Ken >=20 > On Fri, Feb 13, 2015 at 17:32:32 -0700, Kenneth D. Merry wrote: >>=20 >> 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. >>=20 >> A description of the changes is here and below in this message. >>=20 >> If you have tape hardware and the inclination, I'd appreciate testing = and >> feedback. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Rough draft commit message: >>=20 >> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt >>=20 >> The patches against FreeBSD/head as of SVN revision 278706: >>=20 >> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt >>=20 >> And (untested) patches against FreeBSD stable/10 as of SVN revision = 278721. >>=20 >> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The intent is to get the tape infrastructure more up to date, so we = can >> support LTFS and more modern tape drives: >>=20 >> http://www.ibm.com/systems/storage/tape/ltfs/ >>=20 >> I have ported IBM's LTFS Single Drive Edition to FreeBSD. The port = depends >> on the patches linked above. It isn't fully cleaned up and ready for >> redistribution. If you're interested, though, let me know and I'll = tell >> you when it is ready to go out. You need an IBM LTO-5, LTO-6, TS1140 = or >> TS1150 tape drive. HP drives aren't supported by IBM's LTFS, and = older >> drives don't have the necessary features to support LTFS. >>=20 >> The commit message below outlines most of the changes. >>=20 >> A few comments: >>=20 >> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. >>=20 >> 2. The XML output is similar to what GEOM and CTL do. It would be = nice to >> figure out how to put a standard schema on it so that standard = tools >> could read it. I don't know how feasible that is, since I haven't >> time to dig into it. If anyone has suggestions on whether that is >> feasible or advisable, I'd appreciate feedback. >>=20 >> 3. I have tested with a reasonable amount of tape hardware (see below = for a >> list), but more testing and feedback would be good. >>=20 >> 4. Standard 'mt status' output looks like this: >>=20 >> # mt -f /dev/nsa3 status -v >> Drive: sa3: Serial Number: 101500520A >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x5a:LTO-6 variable 384607 enabled (0xff) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >> Residual: 0 Reported File Number: 0 Reported Record Number: 0 >> Flags: BOP >>=20 >> 5. 'mt status -v' looks like this: >>=20 >> # mt -f /dev/nsa3 status -v >> Drive: sa3: Serial Number: 101500520A >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x5a:LTO-6 variable 384607 enabled (0xff) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >> Residual: 0 Reported File Number: 0 Reported Record Number: 0 >> Flags: BOP >> --------------------------------- >> Tape I/O parameters: >> Maximum I/O size allowed by driver and controller (maxio): 1081344 = bytes >> Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes >> Maximum block size supported by tape drive and media (max_blk): = 8388608 bytes >> Minimum block size supported by tape drive and media (min_blk): 1 = bytes >> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >> Maximum possible I/O size (max_effective_iosize): 1081344 bytes >>=20 >> 6. Existing applications should work without changes. If not, please = let >> me know. Hopefully they will move over time to the new interfaces. >>=20 >> 7. There are lots of additional features that could be added later. >> Append-only support, encryption, more log pages, etc. >>=20 >> 8. I have SCSI READ ATTRIBUTE changes for camcontrol(8) that will go = in >> separately. These changes allow displaying the contents of the MAM >> (Medium Auxiliary Memory) chips on LTO, TS and other modern tape = drives. >> These are good, and a future possible direction is adding = attributes=20 >> to the status XML from the sa(4) driver. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Significant upgrades to sa(4) and mt(1). >>=20 >> The primary focus of these changes is to modernize FreeBSD's >> tape infrastructure so that we can take advantage of some of the >> features of modern tape drives and allow support for LTFS. >>=20 >> Significant changes and new features include: >>=20 >> o sa(4) driver status and parameter information is now exported via = an >> XML structure. This will allow for changes and improvements later >> on that will not break userland applications. The old MTIOCGET >> status ioctl remains, so applications using the existing interface >> will not break. >>=20 >> o 'mt status' now reports drive-reported tape position information >> as well as the previously available calculated tape position >> information. These numbers will be different at times, because >> the drive-reported block numbers are relative to BOP (Beginning >> of Partition), but the block numbers calculated previously via >> sa(4) (and still provided) are relative to the last filemark. >> Both numbers are now provided. 'mt status' now also shows the >> drive INQUIRY information, serial number and any position flags >> (BOP, EOT, etc.) provided with the tape position information. >> 'mt status -v' adds information on the maximum possible I/O size, >> and the underlying values used to calculate it. >>=20 >> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. >>=20 >> The extra devices were originally added as place holders for >> density-specific device nodes. Some OSes (NetBSD, NetApp's OnTap >> and Solaris) have had device nodes that, when you write to them, >> will automatically select a given density for particular tape = drives. >>=20 >> This is a convenient way of switching densities, but it was never >> implemented in FreeBSD. Only the device nodes were there, and that >> sometimes confused users. >>=20 >> For modern tape devices, the density is generally not selectable >> (e.g. with LTO) or defaults to the highest availble density when >> the tape is rewritten from BOT (e.g. TS11X0). So, for most users, >> density selection won't be necessary. If they do need to select >> the density, it is easy enough to use 'mt density' to change it. >>=20 >> o Protection information is now supported. This is either a >> Reed-Solomon CRC or CRC32 that is included at the end of each block >> read and written. On write, the tape drive verifies the CRC, and >> on read, the tape drive provides a CRC for the userland application >> to verify. >>=20 >> o New, extensible tape driver parameter get/set interface. >>=20 >> o Density reporting information. For drives that support it, >> 'mt getdensity' will show detailed information on what formats the >> tape drive supports, and what formats the tape drive supports. >>=20 >> o Some mt(1) functionality moved into a new mt(3) library so that >> external applications can reuse the code. >>=20 >> o The new mt(3) library includes helper routines to aid in parsing >> the XML output of the sa(4) driver, and build a tree of driver >> metadata. >>=20 >> o Support for the MTLOAD (load a tape in the drive) and MTWEOFI >> (write filemark immediate) ioctls needed by IBM's LTFS >> implementation. >>=20 >> o Improve device departure behavior for the sa(4) driver. The = previous >> implementation led to hangs when the device was open. >>=20 >> o This has been tested on the following types of drives: >> IBM TS1150 >> IBM TS1140 >> IBM LTO-6 >> IBM LTO-5 >> HP LTO-2 >> Seagate DDS-4 >> Quantum DLT-4000 >> Exabyte 8505 >> Sony DDS-2 >>=20 >> contrib/groff/tmac/doc-syms, >> share/mk/bsd.libnames.mk, >> lib/Makefile, >> Add libmt. >>=20 >> lib/libmt/Makefile, >> lib/libmt/mt.3, >> lib/libmt/mtlib.c, >> lib/libmt/mtlib.h, >> New mt(3) library that contains functions moved from mt(1) and >> new functions needed to interact with the updated sa(4) driver. >>=20 >> This includes XML parser helper functions that application = writers >> can use when writing code to query tape parameters. >>=20 >> rescue/rescue/Makefile: >> Add -lmt to CRUNCH_LIBS. >>=20 >> sys/cam/cam_ccb.h >> Add a new flag value for the XPT_DEV_ADVINFO CCB, = CDAI_FLAG_NONE. >>=20 >> sbin/camcontrol/camcontrol.c, >> sys/cam/scsi/scsi_da.c, >> sys/cam/scsi/scsi_enc_ses.c, >> sys/dev/mps/mps_sas.c: >> Make sure the flags for the XPT_DEV_ADVINFO CCB are set = correctly. >> This prevents unintended attempts to set advanced information >> values when XPT_DEV_ADVINFO CCBs are not pre-zeroed. >>=20 >> src/share/man/man4/mtio.4 >> Clarify this man page a bit, and since it contains what is >> essentially the mtio.h header file, add new ioctls and structure >> definitions from mtio.h. >>=20 >> src/share/man/man4/sa.4 >> Update BUGS and maintainer section. >>=20 >> sys/cam/scsi/scsi_all.c, >> sys/cam/scsi/scsi_all.h: >> Add SCSI SECURITY PROTOCOL IN/OUT CDB definitions and CDB = building >> functions. >>=20 >> sys/cam/scsi/scsi_sa.c >> sys/cam/scsi/scsi_sa.h >> Many tape driver changes, largely outlined above. >>=20 >> Increase the sa(4) driver read/write timeout from 4 to 32 >> minutes. This is based on the recommended values for IBM LTO >> 5/6 drives. This may also avoid timeouts for other tape >> hardware that can take a long time to do retries and error >> recovery. Longer term, a better way to handle this is to ask >> the drive for recommended timeout values using the REPORT >> SUPPORTED OPCODES command. Modern IBM and Oracle tape drives >> at least support that command, and it would allow for more >> accurate timeout values. >>=20 >> Add XML status generation. This is done with a series of >> macros to eliminate as much duplicate code as possible. The >> new XML-based status values are reported through the new >> MTIOCEXTGET ioctl. >>=20 >> Add XML driver parameter reporting, using the new MTIOCPARAMGET >> ioctl. >>=20 >> Add a new driver parameter setting interface, using the new >> MTIOCPARAMSET and MTIOCSETLIST ioctls. >>=20 >> Add a new MTIOCRBLIM ioctl to get block limits information. >>=20 >> Add CCB/CDB building routines scsi_locate_16, scsi_locate_10, >> and scsi_read_position_10(). >>=20 >> scsi_locate_10 implements the LOCATE command, as does the >> existing scsi_set_position() command. It just supports >> additional arguments and features. If/when we figure out a >> good way to provide backward compatibility for older >> applications using the old function API, we can just revamp >> scsi_set_position(). The same goes for >> scsi_read_position_10() and the existing scsi_read_position() >> function. >>=20 >> Revamp sasetpos() to take the new mtlocate structure as an >> argument. It now will use either scsi_locate_10() or >> scsi_locate_16(), depending upon the arguments the user >> supplies. As before, once we change position we don't have a >> clear idea of what the current logical position of the tape >> drive is. >>=20 >> For tape drives that support long form position data, we >> read the current position and store that for later reporting >> after changing the position. This should help applications >> like Bacula speed tape access under FreeBSD once they are >> modified to support the new ioctls. >>=20 >> Add a new quirk, SA_QUIRK_NO_LONG_POS, that is set for all >> drives that report SCSI-2 or older, as well as drives that >> report an Illegal Request type error for READ POSITION with >> the long format. So we should automatically detect drives >> that don't support the long form and stop asking for it after >> an initial try. >>=20 >> Add a partition number to the sa(4) softc. >>=20 >> Improve device departure handling. The previous implementation >> led to hangs when the device was open. >>=20 >> If an application had the sa(4) driver open, and attempted to >> close it after it went away, the cam_periph_release() call in >> saclose() would cause the periph to get destroyed because that >> was the last reference to it. Because destroy_dev() was >> called from the sa(4) driver's cleanup routine (sacleanup()), >> and would block waiting for the close to happen, a deadlock >> would result. >>=20 >> So instead of calling destroy_dev() from the cleanup routine, >> call destroy_dev_sched_cb() from saoninvalidate() and wait for >> the callback. >>=20 >> Acquire a reference for devfs in saregister(), and release it >> in the new sadevgonecb() routine when all devfs devices for=09 >> the particular sa(4) driver instance are gone. >>=20 >> Add a new function, sasetupdev(), to centralize setting >> per-instance devfs device parameters instead of repeating the >> code in saregister(). >>=20 >> Add an open count to the softc, so we know how many >> peripheral driver references are a result of open >> sessions. >>=20 >> Add the D_TRACKCLOSE flag to the cdevsw flags so >> that we get a 1:1 mapping of open to close calls >> instead of a N:1 mapping. >>=20 >> This should be a no-op for everything except the >> control device, since we don't allow more than one >> open on non-control devices. >>=20 >> However, since we do allow multiple opens on the >> control device, the combination of the open count >> and the D_TRACKCLOSE flag should result in an >> accurate peripheral driver reference count, and an >> accurate open count. >>=20 >> The accurate open count allows us to release all >> peripheral driver references that are the result >> of open contexts once we get the callback from devfs. >>=20 >> sys/sys/mtio.h: >> Add a number of new mt(4) ioctls and the requisite data >> structures. None of the existing interfaces been removed >> or changed. >>=20 >> This includes definitions for the following new ioctls: >>=20 >> MTIOCRBLIM /* get block limits */ >> MTIOCEXTLOCATE /* seek to position */ >> MTIOCEXTGET /* get tape status */ >> MTIOCPARAMGET /* get tape params */ >> MTIOCPARAMSET /* set tape params */ >> MTIOCSETLIST /* set N params */ >>=20 >> usr.bin/mt/Makefile: >> mt(1) now depends on libmt, libsbuf and libbsdxml. >>=20 >> usr.bin/mt/mt.1: >> Document new mt(1) features and subcommands. >>=20 >> usr.bin/mt/mt.c: >> Implement support for mt(1) subcommands that need to >> use getopt(3) for their arguments. >>=20 >> Implement a new 'mt status' command to replace the old >> 'mt status' command. The old status command has been >> renamed 'ostatus'. >>=20 >> The new status function uses the MTIOCEXTGET ioctl, and >> therefore parses the XML data to determine drive status. >> The -x argument to 'mt status' allows the user to dump out >> the raw XML reported by the kernel. >>=20 >> The new status display is mostly the same as the old status >> display, except that it doesn't print the redundant density >> mode information, and it does print the current partition >> number and position flags. >>=20 >> Add a new command, 'mt locate', that will supersede the >> old 'mt setspos' and 'mt sethpos' commands. 'mt locate' >> implements all of the functionality of the MTIOCEXTLOCATE >> ioctl, and allows the user to change the logical position >> of the tape drive in a number of ways. (Partition, >> block number, file number, set mark number, end of data.) >> The immediate bit and the explicit address bits are >> implemented, but not documented in the man page. >>=20 >> Add a new 'mt weofi' command to use the new MTWEOFI ioctl. >> This allows the user to ask the drive to write a filemark >> without waiting around for the operation to complete. >>=20 >> Add a new 'mt getdensity' command that gets the XML-based >> tape drive density report from the sa(4) driver and displays >> it. This uses the SCSI REPORT DENSITY SUPPORT command >> to get comprehensive information from the tape drive about >> what formats it is able to read and write. >>=20 >> Add a new 'mt protect' command that allows getting and setting >> tape drive protection information. The protection information >> is a CRC tacked on to the end of every read/write from and to >> the tape drive. >>=20 >> Sponsored by: Spectra Logic >> MFC after: 1 month >>=20 >> Thanks, >>=20 >> Ken >> --=20 >> Kenneth Merry >> ken@FreeBSD.ORG >=20 > --=20 > Kenneth Merry > ken@FreeBSD.ORG > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to = "freebsd-scsi-unsubscribe@freebsd.org" =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 17:10:06 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 CC4FEA38; Sat, 28 Feb 2015 17:10:06 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A383CE8C; Sat, 28 Feb 2015 17:10:05 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id A7E4FA0 ; Sat, 28 Feb 2015 17:10:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> Date: Sat, 28 Feb 2015 12:10:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BF4E4B7-3B9C-42CF-A2D1-F7BD5974D603@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <329C1EFF-FB33-491F-B179-8831039B4698@langille.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) 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: Sat, 28 Feb 2015 17:10:06 -0000 > On Feb 28, 2015, at 11:48 AM, Dan Langille wrote: >=20 >=20 >> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry = wrote: >>=20 >>=20 >> I have updated the patches. >>=20 >> I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since >> I committed those separately. >>=20 >> I have (hopefully) fixed the build for the stable/10 patches by = MFCing >> dependencies. (One of them mav did for me, thanks!) >>=20 >> Rough draft commit message: >>=20 >> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >>=20 >> The patches against FreeBSD/head as of SVN revision 278975: >>=20 >> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt >>=20 >> And (untested) patches against FreeBSD stable/10 as of SVN revision = 278974: >>=20 >> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt >=20 > Not sure what I've done wrong here. >=20 > I've applied your patches and run make buildworld against: It appears 'patch -p0' is my friend... It's been a long time.. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 22:29:52 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 F33AA8B4; Sat, 28 Feb 2015 22:29:51 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CAF48FC; Sat, 28 Feb 2015 22:29:51 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 78C505D1 ; Sat, 28 Feb 2015 22:29:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: sa(4) driver changes available for test From: Dan Langille In-Reply-To: <20150219001347.GA57416@mithlond.kdm.org> Date: Sat, 28 Feb 2015 17:29:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> To: "Kenneth D. Merry" X-Mailer: Apple Mail (2.2070.6) 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: Sat, 28 Feb 2015 22:29:52 -0000 > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >=20 >=20 > I have updated the patches. >=20 > I have removed the XPT_DEV_ADVINFO changes from the patches to head, = since > I committed those separately. >=20 > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) >=20 > Rough draft commit message: >=20 > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt I have current installed and running with Bacula, but I have not tried = the tape drive yet. It seems like your changes are in there from about 5 days ago. Having solved my server hardware issues, I'm now having issues with the = autochanger mechanism=20 of the tape library. =20 =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 23:15:24 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE1DE91A; Sat, 28 Feb 2015 23:15:24 +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 AEC2D7DF; Sat, 28 Feb 2015 23:15:24 +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 t1SNFMA6053061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 28 Feb 2015 16:15:22 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t1SNFMYR053060; Sat, 28 Feb 2015 16:15:22 -0700 (MST) (envelope-from ken) Date: Sat, 28 Feb 2015 16:15:22 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150228231521.GA53017@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45551872-C9F9-4597-BB67-5E853D2CB324@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]); Sat, 28 Feb 2015 16:15:22 -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: Sat, 28 Feb 2015 23:15:25 -0000 On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: > > > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: > > > > > > I have updated the patches. > > > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > > I committed those separately. > > > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > > dependencies. (One of them mav did for me, thanks!) > > > > Rough draft commit message: > > > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > > I have current installed and running with Bacula, but I have not tried the tape drive yet. > Thanks for all your work on this! > It seems like your changes are in there from about 5 days ago. Yes, that is correct. > Having solved my server hardware issues, I'm now having issues with the autochanger mechanism > of the tape library. Does it work with chio(1)? Does it look like hardware or software? (If it is software, I can help with that.) Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 28 23:42:42 2015 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FEF472; Sat, 28 Feb 2015 23:42:42 +0000 (UTC) Received: from clavin1.langille.org (clavin.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26688A6A; Sat, 28 Feb 2015 23:42:41 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 5161467F ; Sat, 28 Feb 2015 23:42:40 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: sa(4) driver changes available for test From: Dan Langille X-Mailer: iPhone Mail (12B466) In-Reply-To: <20150228231521.GA53017@mithlond.kdm.org> Date: Sat, 28 Feb 2015 18:42:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150214003232.GA63990@mithlond.kdm.org> <20150219001347.GA57416@mithlond.kdm.org> <45551872-C9F9-4597-BB67-5E853D2CB324@langille.org> <20150228231521.GA53017@mithlond.kdm.org> To: "Kenneth D. Merry" 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: Sat, 28 Feb 2015 23:42:42 -0000 > On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry wrote: >=20 >> On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote: >>=20 >>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry wrote: >>>=20 >>>=20 >>> I have updated the patches. >>>=20 >>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, sin= ce >>> I committed those separately. >>>=20 >>> I have (hopefully) fixed the build for the stable/10 patches by MFCing >>> dependencies. (One of them mav did for me, thanks!) >>>=20 >>> Rough draft commit message: >>>=20 >>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt >>=20 >>=20 >> I have current installed and running with Bacula, but I have not tried th= e tape drive yet. >=20 > Thanks for all your work on this! >=20 >> It seems like your changes are in there from about 5 days ago. >=20 > Yes, that is correct. >=20 >> Having solved my server hardware issues, I'm now having issues with the a= utochanger mechanism=20 >> of the tape library. =20 >=20 > Does it work with chio(1)? >=20 > Does it look like hardware or software? (If it is software, I can help > with that.) >=20 >=20 Hardware. The screw drive for the tape robot is sticky. It can be moved by h= and, but the motor in this DL 891 cannot. It might need lube. It was suspect= last time I used it. Worst case, I will remove ins of the two DLT 8000 tap= e drives and load tapes manually.=20 --=20 Dan Langille http://langille.org/