From owner-freebsd-scsi@FreeBSD.ORG Sun Mar 1 19:50:01 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 929EDA35; Sun, 1 Mar 2015 19:50:01 +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 52786BDC; Sun, 1 Mar 2015 19:50:00 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 57A1EA1F ; Sun, 1 Mar 2015 19:49:57 +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: Date: Sun, 1 Mar 2015 14:49:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C3D78F7-98C3-40E6-BA20-378A74E0BB35@langille.org> 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" 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: Sun, 01 Mar 2015 19:50:01 -0000 > On Feb 28, 2015, at 6:42 PM, Dan Langille wrote: >=20 >> 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, 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 >>>=20 >>> I have current installed and running with Bacula, but I have not = tried the 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 autochanger 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 >=20 > Hardware. The screw drive for the tape robot is sticky. It can be = moved by hand, 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 tape drives and load tapes manually.=20 A bit of lube, and we have POST: = https://twitter.com/DLangille/status/572117570997919744 More, soon. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Sun Mar 1 22:06:40 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 7C5E26F2; Sun, 1 Mar 2015 22:06:40 +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 33B2FBE2; Sun, 1 Mar 2015 22:06:38 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 3C4E0DF8 ; Sun, 1 Mar 2015 22:06:26 +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: <20150214003232.GA63990@mithlond.kdm.org> Date: Sun, 1 Mar 2015 17:06:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> References: <20150214003232.GA63990@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: Sun, 01 Mar 2015 22:06:40 -0000 > 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 > =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 # mtx -f /dev/pass0 status Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Data Transfer Element 1:Empty Storage Element 1:Empty Storage Element 2:Empty Storage Element 3:Empty Storage Element 4:Full :VolumeTag=3DFAI260 = =20 Storage Element 5:Full :VolumeTag=3DFAI261 = =20 Storage Element 6:Full :VolumeTag=3DFAI262 = =20 Storage Element 7:Full :VolumeTag=3DFAI263 = =20 Storage Element 8:Empty Storage Element 9:Empty Storage Element 10:Empty It was at this point I spent the next 90 minute trying to get the tape=20= drive out of the tape library to free a stuck tape. Some of this was = spent attempting, and failing, to undo a stripped screw. I stopped the = attempt when I noticed the screw did need to be removed. :/ When I do this command, I hear the drive move a bit, to read the tape: # mt -f /dev/nsa1 status Drive: sa1: Serial Number: CXA09S1340 --------------------------------- Mode Density Blocksize bpi Compression Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual: 0 Reported File Number: -1 Reported Record Number: -1 Flags: None # mt -f /dev/nsa1 ostatus =20 Mode Density Blocksize bpi Compression Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC ---------available modes--------- 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 Residual Count 0 After doing a very small tar -c and tar -x, I have: # mt -f /dev/nsa1 /dev/nsa1 ostatus Mode Density Blocksize bpi Compression Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC ---------available modes--------- 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 7 Residual Count 0 # mt -f /dev/nsa1 status -v Drive: sa1: Serial Number: CXA09S1340 --------------------------------- Mode Density Blocksize bpi Compression Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) --------------------------------- Current Driver State: at rest. --------------------------------- Partition: 0 Calc File Number: 0 Calc Record Number: 7 Residual: 0 Reported File Number: -1 Reported Record Number: -1 Flags: None --------------------------------- Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 65536 bytes Maximum I/O size reported by controller (cpi_maxio): 0 bytes Maximum block size supported by tape drive and media (max_blk): = 16777214 bytes Minimum block size supported by tape drive and media (min_blk): 2 = bytes Block granularity supported by tape drive and media (blk_gran): 0 = bytes Maximum possible I/O size (max_effective_iosize): 65536 bytes I may not get to testing Bacula today. =20 Based on the above, is there any commands you'd like me to try? Read below regarding two tape drives >=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. How does this affect a tape library with more than one tape drive? [root@cuppy:~] # camcontrol amcontrol devlist at scbus0 target 0 lun 0 (pass0,ch0) at scbus0 target 2 lun 0 (sa1,pass2) at scbus1 target 0 lun 0 (pass3,ada0) at scbus2 target 0 lun 0 (pass4,ada1) at scbus3 target 0 lun 0 (pass5,ses0) This system has two tapes drives and I can access them through the front = panel but: # ls -l /dev/*sa* crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl ... only one tape drives shows up. >=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 > _______________________________________________ > 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 Mon Mar 2 00:15:12 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 234B3E25; Mon, 2 Mar 2015 00:15:12 +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 E0BC4A01; Mon, 2 Mar 2015 00:15:11 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 96945F61 ; Mon, 2 Mar 2015 00:15:08 +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: Sun, 1 Mar 2015 19:15:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@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: Mon, 02 Mar 2015 00:15:12 -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. >=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. I have this in /usr/local/etc/bacula/bacula-sd.conf Device { Name =3D DLT Description =3D "QUANTUM DLT7000 1624" Media Type =3D DLT Archive Device =3D /dev/nsa1 Autochanger =3D YES Drive Index =3D 0 Offline On Unmount =3D no Hardware End of Medium =3D yes BSF at EOM =3D yes Backward Space Record =3D no Fast Forward Space File =3D no TWO EOF =3D yes } FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a = btape test on this same model. Here's the test I ran tonight: [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 Tape block granularity is 1024 bytes. btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK *test =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D I'm going to write 10000 records and an EOF then write 10000 records and an EOF, then rewind, and re-read the data to verify that it is correct. This is an *essential* feature ... btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1210-0 Rewind OK. 10000 blocks re-read correctly. Got EOF on tape. 10000 blocks re-read correctly. =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D btape: btape.c:1277-0 Block position test btape: btape.c:1289-0 Rewind OK. Reposition to file:block 0:4 Block 5 re-read correctly. Reposition to file:block 0:200 Block 201 re-read correctly. Reposition to file:block 0:9999 Block 10000 re-read correctly. Reposition to file:block 1:0 Block 10001 re-read correctly. Reposition to file:block 1:600 Block 10601 re-read correctly. Reposition to file:block 1:9999 Block 20000 re-read correctly. =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D =3D=3D=3D Append files test =3D=3D=3D This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1420-0 Now moving to end of medium. btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" = (/dev/nsa1). ERR=3DNo error: 0. We should be in file 3. I am at file 0. This is NOT correct!!!! Append test failed. Attempting again. Setting "Hardware End of Medium =3D no and "Fast Forward Space File =3D no and retrying append test. =3D=3D=3D Append files test =3D=3D=3D This test is essential to Bacula. I'm going to write one record in file 0, two records in file 1, and three records in file 2 btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1420-0 Now moving to end of medium. btape: btape.c:625-0 Moved to end of medium. We should be in file 3. I am at file 3. This is correct! Now the important part, I am going to attempt to append to the tape. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) Done appending, there should be no I/O errors Doing Bacula scan of blocks: 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=3D4, blocks=3D7, bytes =3D 451,136 End scanning the tape. We should be in file 4. I am at file 4. This is correct! It looks like the test worked this time, please add: Hardware End of Medium =3D No Fast Forward Space File =3D No to your Device resource in the Storage conf file. The above Bacula scan should have output identical to what follows. Please double check it ... =3D=3D=3D Sample correct output =3D=3D=3D 1 block of 64448 bytes in file 1 End of File mark. 2 blocks of 64448 bytes in file 2 End of File mark. 3 blocks of 64448 bytes in file 3 End of File mark. 1 block of 64448 bytes in file 4 End of File mark. Total files=3D4, blocks=3D7, bytes =3D 451,136 =3D=3D=3D End sample correct output =3D=3D=3D If the above scan output is not identical to the sample output, you MUST correct the problem or Bacula will not be able to write multiple Jobs to=20 the tape. Skipping read backwards test because BSR turned off. =3D=3D=3D Forward space files test =3D=3D=3D This test is essential to Bacula. I'm going to write five files then test forward spacing btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:1907-0 Wrote one record of 64412 bytes. btape: btape.c:1909-0 Wrote block to device. btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1634-0 Now forward spacing 1 file. We should be in file 1. I am at file 1. This is correct! btape: btape.c:1646-0 Now forward spacing 2 files. We should be in file 3. I am at file 3. This is correct! btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1659-0 Now forward spacing 4 files. We should be in file 4. I am at file 4. This is correct! btape: btape.c:1677-0 Now forward spacing 1 more file. We should be in file 5. I am at file 5. This is correct! =3D=3D=3D End Forward space files test =3D=3D=3D Ah, I see you have an autochanger configured. To test the autochanger you must have a blank tape that I can write on in Slot 1. Do you wish to continue with the Autochanger test? (y/n): y =3D=3D=3D Autochanger test =3D=3D=3D 3301 Issuing autochanger "loaded" command. Nothing loaded in the drive. OK. 3303 Issuing autochanger "load 1 0" command. 3303 Autochanger "load 1 0" status is OK. btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) The test autochanger worked!! * >=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.) Errors are interesting to me. Especially corrected errors. They are a = good indicator of tape quality. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 00:18:44 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 0A9A2F89; Mon, 2 Mar 2015 00:18:44 +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 A1D0FA32; Mon, 2 Mar 2015 00:18:43 +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 t220IXO3071820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Mar 2015 17:18:33 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t220IXK4071819; Sun, 1 Mar 2015 17:18:33 -0700 (MST) (envelope-from ken) Date: Sun, 1 Mar 2015 17:18:33 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302001833.GA71528@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A478C5C-7965-498E-9F0F-80192265E310@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]); Sun, 01 Mar 2015 17:18:33 -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: Mon, 02 Mar 2015 00:18:44 -0000 On Sun, Mar 01, 2015 at 17:06:24 -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. > > > > ============ > > Rough draft commit message: > > > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt > > > > The patches against FreeBSD/head as of SVN revision 278706: > > > > http://people.freebsd.org/~ken/sa_changes.20150213.3.txt > > > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. > > > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt > > ============ > > > > The intent is to get the tape infrastructure more up to date, so we can > > support LTFS and more modern tape drives: > > > > http://www.ibm.com/systems/storage/tape/ltfs/ > > > > 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. > > > > The commit message below outlines most of the changes. > > > > A few comments: > > > > 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. > > > > 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. > > > > 3. I have tested with a reasonable amount of tape hardware (see below for a > > list), but more testing and feedback would be good. > > > > 4. Standard 'mt status' output looks like this: > > > > # 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 > > > > 5. 'mt status -v' looks like this: > > > > # 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 > > > # mtx -f /dev/pass0 status > Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) > Data Transfer Element 0:Empty > Data Transfer Element 1:Empty > Storage Element 1:Empty > Storage Element 2:Empty > Storage Element 3:Empty > Storage Element 4:Full :VolumeTag=FAI260 > Storage Element 5:Full :VolumeTag=FAI261 > Storage Element 6:Full :VolumeTag=FAI262 > Storage Element 7:Full :VolumeTag=FAI263 > Storage Element 8:Empty > Storage Element 9:Empty > Storage Element 10:Empty > > > It was at this point I spent the next 90 minute trying to get the tape > drive out of the tape library to free a stuck tape. Some of this was spent > attempting, and failing, to undo a stripped screw. I stopped the attempt when > I noticed the screw did need to be removed. :/ Thanks for all of the effort! Looks like it is paying off! :) > When I do this command, I hear the drive move a bit, to read the tape: > > # mt -f /dev/nsa1 status > Drive: sa1: Serial Number: CXA09S1340 > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: -1 Reported Record Number: -1 > Flags: None Looks like the drive isn't reporting position information. It will still be useful to try it with Bacula, though. > # mt -f /dev/nsa1 ostatus > Mode Density Blocksize bpi Compression > Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > ---------available modes--------- > 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 Residual Count 0 > > > After doing a very small tar -c and tar -x, I have: > > # mt -f /dev/nsa1 /dev/nsa1 ostatus > Mode Density Blocksize bpi Compression > Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > ---------available modes--------- > 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 7 Residual Count 0 Woohoo! It works. > # mt -f /dev/nsa1 status -v > Drive: sa1: Serial Number: CXA09S1340 > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 7 > Residual: 0 Reported File Number: -1 Reported Record Number: -1 > Flags: None > --------------------------------- > Tape I/O parameters: > Maximum I/O size allowed by driver and controller (maxio): 65536 bytes > Maximum I/O size reported by controller (cpi_maxio): 0 bytes > Maximum block size supported by tape drive and media (max_blk): 16777214 bytes > Minimum block size supported by tape drive and media (min_blk): 2 bytes > Block granularity supported by tape drive and media (blk_gran): 0 bytes > Maximum possible I/O size (max_effective_iosize): 65536 bytes > > I may not get to testing Bacula today. > > Based on the above, is there any commands you'd like me to try? Aside from making sure things work okay with Bacula, that is probably sufficient. These drives won't support density reports or position information. > Read below regarding two tape drives > > > > > 6. Existing applications should work without changes. If not, please let > > me know. Hopefully they will move over time to the new interfaces. > > > > 7. There are lots of additional features that could be added later. > > Append-only support, encryption, more log pages, etc. > > > > 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 > > to the status XML from the sa(4) driver. > > > > ============ > > Significant upgrades to sa(4) and mt(1). > > > > 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. > > > > Significant changes and new features include: > > > > 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. > > > > 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. > > > > o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. > > How does this affect a tape library with more than one tape drive? > > [root@cuppy:~] # camcontrol amcontrol devlist > at scbus0 target 0 lun 0 (pass0,ch0) > at scbus0 target 2 lun 0 (sa1,pass2) > at scbus1 target 0 lun 0 (pass3,ada0) > at scbus2 target 0 lun 0 (pass4,ada1) > at scbus3 target 0 lun 0 (pass5,ses0) > > This system has two tapes drives and I can access them through the front panel but: > > # ls -l /dev/*sa* > crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 > crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 > crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 > crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl > > ... only one tape drives shows up. Hmm. The tape drive is listed as sa1, which implies that there may be an sa0 that was there previously or is in the process of probing. What does dmesg show? How about 'camcontrol devlist -v'? I would look at cabling and termination. Is this your library? http://manx.classiccmp.org/collections/mds-199909/cd3/tape/tl891uga.pdf If it is close enough, there are 6 connectors on the back. You would want to have something plugged into all 6, either a cable or a terminator. In the manual above, the SCSI IDs are set via the front panel. If the other drive is on the same bus as the drive above and the library device, it should be at a separate SCSI ID. > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > o New, extensible tape driver parameter get/set interface. > > > > 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. > > > > o Some mt(1) functionality moved into a new mt(3) library so that > > external applications can reuse the code. > > > > 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. > > > > o Support for the MTLOAD (load a tape in the drive) and MTWEOFI > > (write filemark immediate) ioctls needed by IBM's LTFS > > implementation. > > > > o Improve device departure behavior for the sa(4) driver. The previous > > implementation led to hangs when the device was open. > > > > 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 > > > > contrib/groff/tmac/doc-syms, > > share/mk/bsd.libnames.mk, > > lib/Makefile, > > Add libmt. > > > > 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. > > > > This includes XML parser helper functions that application writers > > can use when writing code to query tape parameters. > > > > rescue/rescue/Makefile: > > Add -lmt to CRUNCH_LIBS. > > > > sys/cam/cam_ccb.h > > Add a new flag value for the XPT_DEV_ADVINFO CCB, CDAI_FLAG_NONE. > > > > 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. > > > > 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. > > > > src/share/man/man4/sa.4 > > Update BUGS and maintainer section. > > > > sys/cam/scsi/scsi_all.c, > > sys/cam/scsi/scsi_all.h: > > Add SCSI SECURITY PROTOCOL IN/OUT CDB definitions and CDB building > > functions. > > > > sys/cam/scsi/scsi_sa.c > > sys/cam/scsi/scsi_sa.h > > Many tape driver changes, largely outlined above. > > > > 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. > > > > 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. > > > > Add XML driver parameter reporting, using the new MTIOCPARAMGET > > ioctl. > > > > Add a new driver parameter setting interface, using the new > > MTIOCPARAMSET and MTIOCSETLIST ioctls. > > > > Add a new MTIOCRBLIM ioctl to get block limits information. > > > > Add CCB/CDB building routines scsi_locate_16, scsi_locate_10, > > and scsi_read_position_10(). > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > Add a partition number to the sa(4) softc. > > > > Improve device departure handling. The previous implementation > > led to hangs when the device was open. > > > > 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. > > > > So instead of calling destroy_dev() from the cleanup routine, > > call destroy_dev_sched_cb() from saoninvalidate() and wait for > > the callback. > > > > Acquire a reference for devfs in saregister(), and release it > > in the new sadevgonecb() routine when all devfs devices for > > the particular sa(4) driver instance are gone. > > > > Add a new function, sasetupdev(), to centralize setting > > per-instance devfs device parameters instead of repeating the > > code in saregister(). > > > > Add an open count to the softc, so we know how many > > peripheral driver references are a result of open > > sessions. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > This includes definitions for the following new ioctls: > > > > MTIOCRBLIM /* get block limits */ > > MTIOCEXTLOCATE /* seek to position */ > > MTIOCEXTGET /* get tape status */ > > MTIOCPARAMGET /* get tape params */ > > MTIOCPARAMSET /* set tape params */ > > MTIOCSETLIST /* set N params */ > > > > usr.bin/mt/Makefile: > > mt(1) now depends on libmt, libsbuf and libbsdxml. > > > > usr.bin/mt/mt.1: > > Document new mt(1) features and subcommands. > > > > usr.bin/mt/mt.c: > > Implement support for mt(1) subcommands that need to > > use getopt(3) for their arguments. > > > > Implement a new 'mt status' command to replace the old > > 'mt status' command. The old status command has been > > renamed 'ostatus'. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > Sponsored by: Spectra Logic > > MFC after: 1 month > > > > Thanks, > > > > Ken > > -- > > 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" > > ? > Dan Langille > http://langille.org/ > > > > > -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 00:28:40 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 6F1EC2BB; Mon, 2 Mar 2015 00:28:40 +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 19F7DB58; Mon, 2 Mar 2015 00:28:39 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id ABDBAF64 ; Mon, 2 Mar 2015 00:28:38 +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: <20150302001833.GA71528@mithlond.kdm.org> Date: Sun, 1 Mar 2015 19:28:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@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: Mon, 02 Mar 2015 00:28:40 -0000 > On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry wrote: >=20 > On Sun, Mar 01, 2015 at 17:06:24 -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 >>> =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 >>=20 >> # mtx -f /dev/pass0 status >> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) >> Data Transfer Element 0:Empty >> Data Transfer Element 1:Empty >> Storage Element 1:Empty >> Storage Element 2:Empty >> Storage Element 3:Empty >> Storage Element 4:Full :VolumeTag=3DFAI260 = =20 >> Storage Element 5:Full :VolumeTag=3DFAI261 = =20 >> Storage Element 6:Full :VolumeTag=3DFAI262 = =20 >> Storage Element 7:Full :VolumeTag=3DFAI263 = =20 >> Storage Element 8:Empty >> Storage Element 9:Empty >> Storage Element 10:Empty >>=20 >>=20 >> It was at this point I spent the next 90 minute trying to get the = tape=20 >> drive out of the tape library to free a stuck tape. Some of this was = spent >> attempting, and failing, to undo a stripped screw. I stopped the = attempt when >> I noticed the screw did need to be removed. :/ >=20 > Thanks for all of the effort! Looks like it is paying off! :) >=20 >> When I do this command, I hear the drive move a bit, to read the = tape: >>=20 >> # mt -f /dev/nsa1 status >> Drive: sa1: Serial Number: CXA09S1340 >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >> Residual: 0 Reported File Number: -1 Reported Record Number: -1 >> Flags: None >=20 > Looks like the drive isn't reporting position information. It will = still > be useful to try it with Bacula, though. >=20 >> # mt -f /dev/nsa1 ostatus =20 >> Mode Density Blocksize bpi Compression >> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> ---------available modes--------- >> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> File Number: 0 Record Number: 0 Residual Count 0 >>=20 >>=20 >> After doing a very small tar -c and tar -x, I have: >>=20 >> # mt -f /dev/nsa1 /dev/nsa1 ostatus >> Mode Density Blocksize bpi Compression >> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> ---------available modes--------- >> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> File Number: 0 Record Number: 7 Residual Count 0 >=20 > Woohoo! It works. >=20 >> # mt -f /dev/nsa1 status -v >> Drive: sa1: Serial Number: CXA09S1340 >> --------------------------------- >> Mode Density Blocksize bpi Compression >> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >> --------------------------------- >> Current Driver State: at rest. >> --------------------------------- >> Partition: 0 Calc File Number: 0 Calc Record Number: 7 >> Residual: 0 Reported File Number: -1 Reported Record Number: -1 >> Flags: None >> --------------------------------- >> Tape I/O parameters: >> Maximum I/O size allowed by driver and controller (maxio): 65536 = bytes >> Maximum I/O size reported by controller (cpi_maxio): 0 bytes >> Maximum block size supported by tape drive and media (max_blk): = 16777214 bytes >> Minimum block size supported by tape drive and media (min_blk): 2 = bytes >> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >> Maximum possible I/O size (max_effective_iosize): 65536 bytes >>=20 >> I may not get to testing Bacula today. =20 >>=20 >> Based on the above, is there any commands you'd like me to try? >=20 > Aside from making sure things work okay with Bacula, that is probably > sufficient. These drives won't support density reports or position > information. >=20 >> Read below regarding two tape drives >>=20 >>>=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 >> How does this affect a tape library with more than one tape drive? >>=20 >> [root@cuppy:~] # camcontrol amcontrol devlist >> at scbus0 target 0 lun 0 = (pass0,ch0) >> at scbus0 target 2 lun 0 = (sa1,pass2) >> at scbus1 target 0 lun 0 = (pass3,ada0) >> at scbus2 target 0 lun 0 = (pass4,ada1) >> at scbus3 target 0 lun 0 = (pass5,ses0) >>=20 >> This system has two tapes drives and I can access them through the = front panel but: >>=20 >> # ls -l /dev/*sa* >> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 >> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 >> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 >> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl >>=20 >> ... only one tape drives shows up. >=20 >=20 > Hmm. The tape drive is listed as sa1, which implies that there may be = an > sa0 that was there previously or is in the process of probing. What = does > dmesg show? How about 'camcontrol devlist -v'? # camcontrol devlist -v scbus0 on ahc0 bus 0: at scbus0 target 0 lun 0 (pass0,ch0) at scbus0 target 2 lun 0 (sa1,pass2) <> at scbus0 target -1 lun ffffffff () scbus1 on ahcich2 bus 0: at scbus1 target 0 lun 0 (pass3,ada0) <> at scbus1 target -1 lun ffffffff () scbus2 on ahcich4 bus 0: at scbus2 target 0 lun 0 (pass4,ada1) <> at scbus2 target -1 lun ffffffff () scbus3 on ahciem0 bus 0: at scbus3 target 0 lun 0 (pass5,ses0) <> at scbus3 target -1 lun ffffffff () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun ffffffff = (xpt0) BUT! # grep sa /var/run/dmesg.boot=20 VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error 19 alc0: Using 1 MSIX message(s). isab0: at device 31.0 on pci0 isa0: on isab0 orm0: at iomem 0xce800-0xcefff on isa0 atkbdc0: at port 0x60,0x64 on isa0 sa0 at ahc0 bus 0 scbus0 target 1 lun 0 sa0: Removable Sequential Access SCSI-2 = device=20 sa0: Serial Number CXA22S2338 sa0: 10.000MB/s transfers (10.000MHz, offset 15) sa0: quirks=3D0x100 sa1 at ahc0 bus 0 scbus0 target 2 lun 0 sa1: Removable Sequential Access SCSI-2 = device=20 sa1: Serial Number CXA09S1340 sa1: 10.000MB/s transfers (10.000MHz, offset 15) sa1: quirks=3D0x100 >=20 > I would look at cabling and termination. Is this your library? Yes, it is. =20 >=20 > = http://manx.classiccmp.org/collections/mds-199909/cd3/tape/tl891uga.pdf >=20 > If it is close enough, there are 6 connectors on the back. You would = want > to have something plugged into all 6, either a cable or a terminator. Yes, that's mine, and yes, there's two short cables, a terminator, and = the cable to the SCSI card in my computer. >=20 > In the manual above, the SCSI IDs are set via the front panel. If the > other drive is on the same bus as the drive above and the library = device, > it should be at a separate SCSI ID. I did have the entire thing torn apart today, to extract a tape which = would not budge. >=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 >>> _______________________________________________ >>> 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" >>=20 >> ?=20 >> Dan Langille >> http://langille.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 00:31:53 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 CAF2248F; Mon, 2 Mar 2015 00:31:53 +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 771B7C0C; Mon, 2 Mar 2015 00:31:53 +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 t220Vo4q072240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Mar 2015 17:31:50 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t220VoNw072239; Sun, 1 Mar 2015 17:31:50 -0700 (MST) (envelope-from ken) Date: Sun, 1 Mar 2015 17:31:50 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302003150.GB71528@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@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]); Sun, 01 Mar 2015 17:31:50 -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: Mon, 02 Mar 2015 00:31:53 -0000 On Sun, Mar 01, 2015 at 19:15:05 -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. > > > > 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 have this in /usr/local/etc/bacula/bacula-sd.conf > > Device { > Name = DLT > Description = "QUANTUM DLT7000 1624" > Media Type = DLT > Archive Device = /dev/nsa1 > > Autochanger = YES > Drive Index = 0 > > Offline On Unmount = no > Hardware End of Medium = yes > BSF at EOM = yes > Backward Space Record = no > Fast Forward Space File = no > TWO EOF = yes > } > > FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model. > > Here's the test I ran tonight: > > [root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 > Tape block granularity is 1024 bytes. > btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. > btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > *test > > === Write, rewind, and re-read test === > > I'm going to write 10000 records and an EOF > then write 10000 records and an EOF, then rewind, > and re-read the data to verify that it is correct. > > This is an *essential* feature ... > > btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1210-0 Rewind OK. > 10000 blocks re-read correctly. > Got EOF on tape. > 10000 blocks re-read correctly. > === Test Succeeded. End Write, rewind, and re-read test === > > btape: btape.c:1277-0 Block position test > btape: btape.c:1289-0 Rewind OK. > Reposition to file:block 0:4 > Block 5 re-read correctly. > Reposition to file:block 0:200 > Block 201 re-read correctly. > Reposition to file:block 0:9999 > Block 10000 re-read correctly. > Reposition to file:block 1:0 > Block 10001 re-read correctly. > Reposition to file:block 1:600 > Block 10601 re-read correctly. > Reposition to file:block 1:9999 > Block 20000 re-read correctly. > === Test Succeeded. End Write, rewind, and re-read test === > > > > === Append files test === > > This test is essential to Bacula. > > I'm going to write one record in file 0, > two records in file 1, > and three records in file 2 > > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1420-0 Now moving to end of medium. This is the critical piece. The test moves the tape to the end of the medium. With hardware position information, you can tell what filemark you're on. Without it, you can't. > btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0. > We should be in file 3. I am at file 0. This is NOT correct!!!! > > Append test failed. Attempting again. > Setting "Hardware End of Medium = no > and "Fast Forward Space File = no > and retrying append test. This is not surprsing, given that the drive doesn't support long read position data. (It's a SCSI-2 device.) So that means that Bacula will need to do it manually. > === Append files test === > > This test is essential to Bacula. > > I'm going to write one record in file 0, > two records in file 1, > and three records in file 2 > > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1420-0 Now moving to end of medium. > btape: btape.c:625-0 Moved to end of medium. > We should be in file 3. I am at file 3. This is correct! > > Now the important part, I am going to attempt to append to the tape. > > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > Done appending, there should be no I/O errors > > Doing Bacula scan of blocks: > 1 block of 64448 bytes in file 1 > End of File mark. > 2 blocks of 64448 bytes in file 2 > End of File mark. > 3 blocks of 64448 bytes in file 3 > End of File mark. > 1 block of 64448 bytes in file 4 > End of File mark. > Total files=4, blocks=7, bytes = 451,136 > End scanning the tape. > We should be in file 4. I am at file 4. This is correct! > > > It looks like the test worked this time, please add: > > Hardware End of Medium = No > > Fast Forward Space File = No > to your Device resource in the Storage conf file. > > The above Bacula scan should have output identical to what follows. > Please double check it ... > === Sample correct output === > 1 block of 64448 bytes in file 1 > End of File mark. > 2 blocks of 64448 bytes in file 2 > End of File mark. > 3 blocks of 64448 bytes in file 3 > End of File mark. > 1 block of 64448 bytes in file 4 > End of File mark. > Total files=4, blocks=7, bytes = 451,136 > === End sample correct output === > > If the above scan output is not identical to the > sample output, you MUST correct the problem > or Bacula will not be able to write multiple Jobs to > the tape. > > Skipping read backwards test because BSR turned off. > > > === Forward space files test === > > This test is essential to Bacula. > > I'm going to write five files then test forward spacing > > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:1907-0 Wrote one record of 64412 bytes. > btape: btape.c:1909-0 Wrote block to device. > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1634-0 Now forward spacing 1 file. > We should be in file 1. I am at file 1. This is correct! > btape: btape.c:1646-0 Now forward spacing 2 files. > We should be in file 3. I am at file 3. This is correct! > btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1659-0 Now forward spacing 4 files. > We should be in file 4. I am at file 4. This is correct! > > btape: btape.c:1677-0 Now forward spacing 1 more file. > We should be in file 5. I am at file 5. This is correct! > > === End Forward space files test === > > > Ah, I see you have an autochanger configured. > To test the autochanger you must have a blank tape > that I can write on in Slot 1. > > Do you wish to continue with the Autochanger test? (y/n): y > > > === Autochanger test === > > 3301 Issuing autochanger "loaded" command. > Nothing loaded in the drive. OK. > 3303 Issuing autochanger "load 1 0" command. > 3303 Autochanger "load 1 0" status is OK. > btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) > btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) > > The test autochanger worked!! Great, thanks for running the test! Looks like things are working as well as they were before. > > > >> 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.) > > Errors are interesting to me. Especially corrected errors. They are a good indicator of tape quality. > Yes. At least on modern drives, there is a good bit available in the log pages. You can try seeing what logs your drive supports by installing the sg3_utils package and running 'sg_logs sa1 --all'. Given the large amount of data available on some drives, and the difficulty distilling it down to a clear good/bad, I probably won't stick that in the 'mt status' output. But you can certainly take a look at it and have an idea of whether your particular tape/drive are experiencing issues. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 00:37: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 497E35EA; Mon, 2 Mar 2015 00:37: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 BD3F4C37; Mon, 2 Mar 2015 00:37:02 +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 t220aw4k072311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Mar 2015 17:36:58 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t220aw8f072310; Sun, 1 Mar 2015 17:36:58 -0700 (MST) (envelope-from ken) Date: Sun, 1 Mar 2015 17:36:58 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302003658.GA72258@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6C82281F-649A-4DA8-8ACF-17E81C04F730@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]); Sun, 01 Mar 2015 17:36:58 -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: Mon, 02 Mar 2015 00:37:03 -0000 On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry wrote: > > > > On Sun, Mar 01, 2015 at 17:06:24 -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. > >>> > >>> ============ > >>> Rough draft commit message: > >>> > >>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt > >>> > >>> The patches against FreeBSD/head as of SVN revision 278706: > >>> > >>> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt > >>> > >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. > >>> > >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt > >>> ============ > >>> > >>> The intent is to get the tape infrastructure more up to date, so we can > >>> support LTFS and more modern tape drives: > >>> > >>> http://www.ibm.com/systems/storage/tape/ltfs/ > >>> > >>> 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. > >>> > >>> The commit message below outlines most of the changes. > >>> > >>> A few comments: > >>> > >>> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. > >>> > >>> 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. > >>> > >>> 3. I have tested with a reasonable amount of tape hardware (see below for a > >>> list), but more testing and feedback would be good. > >>> > >>> 4. Standard 'mt status' output looks like this: > >>> > >>> # 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 > >>> > >>> 5. 'mt status -v' looks like this: > >>> > >>> # 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 > >> > >> > >> # mtx -f /dev/pass0 status > >> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) > >> Data Transfer Element 0:Empty > >> Data Transfer Element 1:Empty > >> Storage Element 1:Empty > >> Storage Element 2:Empty > >> Storage Element 3:Empty > >> Storage Element 4:Full :VolumeTag=FAI260 > >> Storage Element 5:Full :VolumeTag=FAI261 > >> Storage Element 6:Full :VolumeTag=FAI262 > >> Storage Element 7:Full :VolumeTag=FAI263 > >> Storage Element 8:Empty > >> Storage Element 9:Empty > >> Storage Element 10:Empty > >> > >> > >> It was at this point I spent the next 90 minute trying to get the tape > >> drive out of the tape library to free a stuck tape. Some of this was spent > >> attempting, and failing, to undo a stripped screw. I stopped the attempt when > >> I noticed the screw did need to be removed. :/ > > > > Thanks for all of the effort! Looks like it is paying off! :) > > > >> When I do this command, I hear the drive move a bit, to read the tape: > >> > >> # mt -f /dev/nsa1 status > >> Drive: sa1: Serial Number: CXA09S1340 > >> --------------------------------- > >> Mode Density Blocksize bpi Compression > >> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >> --------------------------------- > >> Current Driver State: at rest. > >> --------------------------------- > >> Partition: 0 Calc File Number: 0 Calc Record Number: 0 > >> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >> Flags: None > > > > Looks like the drive isn't reporting position information. It will still > > be useful to try it with Bacula, though. > > > >> # mt -f /dev/nsa1 ostatus > >> Mode Density Blocksize bpi Compression > >> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> ---------available modes--------- > >> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> --------------------------------- > >> Current Driver State: at rest. > >> --------------------------------- > >> File Number: 0 Record Number: 0 Residual Count 0 > >> > >> > >> After doing a very small tar -c and tar -x, I have: > >> > >> # mt -f /dev/nsa1 /dev/nsa1 ostatus > >> Mode Density Blocksize bpi Compression > >> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> ---------available modes--------- > >> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >> --------------------------------- > >> Current Driver State: at rest. > >> --------------------------------- > >> File Number: 0 Record Number: 7 Residual Count 0 > > > > Woohoo! It works. > > > >> # mt -f /dev/nsa1 status -v > >> Drive: sa1: Serial Number: CXA09S1340 > >> --------------------------------- > >> Mode Density Blocksize bpi Compression > >> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >> --------------------------------- > >> Current Driver State: at rest. > >> --------------------------------- > >> Partition: 0 Calc File Number: 0 Calc Record Number: 7 > >> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >> Flags: None > >> --------------------------------- > >> Tape I/O parameters: > >> Maximum I/O size allowed by driver and controller (maxio): 65536 bytes > >> Maximum I/O size reported by controller (cpi_maxio): 0 bytes > >> Maximum block size supported by tape drive and media (max_blk): 16777214 bytes > >> Minimum block size supported by tape drive and media (min_blk): 2 bytes > >> Block granularity supported by tape drive and media (blk_gran): 0 bytes > >> Maximum possible I/O size (max_effective_iosize): 65536 bytes > >> > >> I may not get to testing Bacula today. > >> > >> Based on the above, is there any commands you'd like me to try? > > > > Aside from making sure things work okay with Bacula, that is probably > > sufficient. These drives won't support density reports or position > > information. > > > >> Read below regarding two tape drives > >> > >>> > >>> 6. Existing applications should work without changes. If not, please let > >>> me know. Hopefully they will move over time to the new interfaces. > >>> > >>> 7. There are lots of additional features that could be added later. > >>> Append-only support, encryption, more log pages, etc. > >>> > >>> 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 > >>> to the status XML from the sa(4) driver. > >>> > >>> ============ > >>> Significant upgrades to sa(4) and mt(1). > >>> > >>> 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. > >>> > >>> Significant changes and new features include: > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. > >> > >> How does this affect a tape library with more than one tape drive? > >> > >> [root@cuppy:~] # camcontrol amcontrol devlist > >> at scbus0 target 0 lun 0 (pass0,ch0) > >> at scbus0 target 2 lun 0 (sa1,pass2) > >> at scbus1 target 0 lun 0 (pass3,ada0) > >> at scbus2 target 0 lun 0 (pass4,ada1) > >> at scbus3 target 0 lun 0 (pass5,ses0) > >> > >> This system has two tapes drives and I can access them through the front panel but: > >> > >> # ls -l /dev/*sa* > >> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 > >> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 > >> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 > >> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl > >> > >> ... only one tape drives shows up. > > > > > > Hmm. The tape drive is listed as sa1, which implies that there may be an > > sa0 that was there previously or is in the process of probing. What does > > dmesg show? How about 'camcontrol devlist -v'? > > # camcontrol devlist -v > scbus0 on ahc0 bus 0: > at scbus0 target 0 lun 0 (pass0,ch0) > at scbus0 target 2 lun 0 (sa1,pass2) > <> at scbus0 target -1 lun ffffffff () > scbus1 on ahcich2 bus 0: > at scbus1 target 0 lun 0 (pass3,ada0) > <> at scbus1 target -1 lun ffffffff () > scbus2 on ahcich4 bus 0: > at scbus2 target 0 lun 0 (pass4,ada1) > <> at scbus2 target -1 lun ffffffff () > scbus3 on ahciem0 bus 0: > at scbus3 target 0 lun 0 (pass5,ses0) > <> at scbus3 target -1 lun ffffffff () > scbus-1 on xpt0 bus 0: > <> at scbus-1 target -1 lun ffffffff (xpt0) > > > BUT! > > # grep sa /var/run/dmesg.boot > VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID > module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error 19 > alc0: Using 1 MSIX message(s). > isab0: at device 31.0 on pci0 > isa0: on isab0 > orm0: at iomem 0xce800-0xcefff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: Serial Number CXA22S2338 > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > sa0: quirks=0x100 > sa1 at ahc0 bus 0 scbus0 target 2 lun 0 > sa1: Removable Sequential Access SCSI-2 device > sa1: Serial Number CXA09S1340 > sa1: 10.000MB/s transfers (10.000MHz, offset 15) > sa1: quirks=0x100 If you run 'dmesg', you should have seen a message when it went away. Perhaps there will be something preceding it that will give us a clue about the problem. (Generally a selection timeout.) At least this does show that sa0 is at target 1, and so should not conflict with the library or sa1. > > > > I would look at cabling and termination. Is this your library? > > Yes, it is. > > > > > http://manx.classiccmp.org/collections/mds-199909/cd3/tape/tl891uga.pdf > > > > If it is close enough, there are 6 connectors on the back. You would want > > to have something plugged into all 6, either a cable or a terminator. > > Yes, that's mine, and yes, there's two short cables, a terminator, and the cable to the SCSI card in my computer. That sounds correct for a configuration with everything on one bus. > > > > In the manual above, the SCSI IDs are set via the front panel. If the > > other drive is on the same bus as the drive above and the library device, > > it should be at a separate SCSI ID. > > I did have the entire thing torn apart today, to extract a tape which would not budge. Ahh. The SCSI IDs are right, so that doesn't appear to be the issue. > > > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> o New, extensible tape driver parameter get/set interface. > >>> > >>> 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. > >>> > >>> o Some mt(1) functionality moved into a new mt(3) library so that > >>> external applications can reuse the code. > >>> > >>> 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. > >>> > >>> o Support for the MTLOAD (load a tape in the drive) and MTWEOFI > >>> (write filemark immediate) ioctls needed by IBM's LTFS > >>> implementation. > >>> > >>> o Improve device departure behavior for the sa(4) driver. The previous > >>> implementation led to hangs when the device was open. > >>> > >>> 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 > >>> > >>> contrib/groff/tmac/doc-syms, > >>> share/mk/bsd.libnames.mk, > >>> lib/Makefile, > >>> Add libmt. > >>> > >>> 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. > >>> > >>> This includes XML parser helper functions that application writers > >>> can use when writing code to query tape parameters. > >>> > >>> rescue/rescue/Makefile: > >>> Add -lmt to CRUNCH_LIBS. > >>> > >>> sys/cam/cam_ccb.h > >>> Add a new flag value for the XPT_DEV_ADVINFO CCB, CDAI_FLAG_NONE. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> src/share/man/man4/sa.4 > >>> Update BUGS and maintainer section. > >>> > >>> sys/cam/scsi/scsi_all.c, > >>> sys/cam/scsi/scsi_all.h: > >>> Add SCSI SECURITY PROTOCOL IN/OUT CDB definitions and CDB building > >>> functions. > >>> > >>> sys/cam/scsi/scsi_sa.c > >>> sys/cam/scsi/scsi_sa.h > >>> Many tape driver changes, largely outlined above. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> Add XML driver parameter reporting, using the new MTIOCPARAMGET > >>> ioctl. > >>> > >>> Add a new driver parameter setting interface, using the new > >>> MTIOCPARAMSET and MTIOCSETLIST ioctls. > >>> > >>> Add a new MTIOCRBLIM ioctl to get block limits information. > >>> > >>> Add CCB/CDB building routines scsi_locate_16, scsi_locate_10, > >>> and scsi_read_position_10(). > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> Add a partition number to the sa(4) softc. > >>> > >>> Improve device departure handling. The previous implementation > >>> led to hangs when the device was open. > >>> > >>> 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. > >>> > >>> So instead of calling destroy_dev() from the cleanup routine, > >>> call destroy_dev_sched_cb() from saoninvalidate() and wait for > >>> the callback. > >>> > >>> Acquire a reference for devfs in saregister(), and release it > >>> in the new sadevgonecb() routine when all devfs devices for > >>> the particular sa(4) driver instance are gone. > >>> > >>> Add a new function, sasetupdev(), to centralize setting > >>> per-instance devfs device parameters instead of repeating the > >>> code in saregister(). > >>> > >>> Add an open count to the softc, so we know how many > >>> peripheral driver references are a result of open > >>> sessions. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> This includes definitions for the following new ioctls: > >>> > >>> MTIOCRBLIM /* get block limits */ > >>> MTIOCEXTLOCATE /* seek to position */ > >>> MTIOCEXTGET /* get tape status */ > >>> MTIOCPARAMGET /* get tape params */ > >>> MTIOCPARAMSET /* set tape params */ > >>> MTIOCSETLIST /* set N params */ > >>> > >>> usr.bin/mt/Makefile: > >>> mt(1) now depends on libmt, libsbuf and libbsdxml. > >>> > >>> usr.bin/mt/mt.1: > >>> Document new mt(1) features and subcommands. > >>> > >>> usr.bin/mt/mt.c: > >>> Implement support for mt(1) subcommands that need to > >>> use getopt(3) for their arguments. > >>> > >>> Implement a new 'mt status' command to replace the old > >>> 'mt status' command. The old status command has been > >>> renamed 'ostatus'. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> Sponsored by: Spectra Logic > >>> MFC after: 1 month > >>> > >>> Thanks, > >>> > >>> Ken > >>> -- > >>> 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" > >> > >> ? > >> Dan Langille > >> http://langille.org/ > >> > >> > >> > >> > >> > > > > -- > > Kenneth Merry > > ken@FreeBSD.ORG > > ? > Dan Langille > http://langille.org/ > > > > > Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 00:40:43 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 45959E1F; Mon, 2 Mar 2015 00:40:43 +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 19AFFD04; Mon, 2 Mar 2015 00:40:42 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id BA8C0F6E ; Mon, 2 Mar 2015 00:40:41 +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: <20150302003658.GA72258@mithlond.kdm.org> Date: Sun, 1 Mar 2015 19:40:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> <20150302003658.GA72258@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: Mon, 02 Mar 2015 00:40:43 -0000 > On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry wrote: >=20 > On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: >>=20 >>> On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sun, Mar 01, 2015 at 17:06:24 -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 >>>>> =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 >>>>=20 >>>> # mtx -f /dev/pass0 status >>>> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) >>>> Data Transfer Element 0:Empty >>>> Data Transfer Element 1:Empty >>>> Storage Element 1:Empty >>>> Storage Element 2:Empty >>>> Storage Element 3:Empty >>>> Storage Element 4:Full :VolumeTag=3DFAI260 = =20 >>>> Storage Element 5:Full :VolumeTag=3DFAI261 = =20 >>>> Storage Element 6:Full :VolumeTag=3DFAI262 = =20 >>>> Storage Element 7:Full :VolumeTag=3DFAI263 = =20 >>>> Storage Element 8:Empty >>>> Storage Element 9:Empty >>>> Storage Element 10:Empty >>>>=20 >>>>=20 >>>> It was at this point I spent the next 90 minute trying to get the = tape=20 >>>> drive out of the tape library to free a stuck tape. Some of this = was spent >>>> attempting, and failing, to undo a stripped screw. I stopped the = attempt when >>>> I noticed the screw did need to be removed. :/ >>>=20 >>> Thanks for all of the effort! Looks like it is paying off! :) >>>=20 >>>> When I do this command, I hear the drive move a bit, to read the = tape: >>>>=20 >>>> # mt -f /dev/nsa1 status >>>> Drive: sa1: Serial Number: CXA09S1340 >>>> --------------------------------- >>>> Mode Density Blocksize bpi = Compression >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >>>> --------------------------------- >>>> Current Driver State: at rest. >>>> --------------------------------- >>>> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >>>> Residual: 0 Reported File Number: -1 Reported Record Number: = -1 >>>> Flags: None >>>=20 >>> Looks like the drive isn't reporting position information. It will = still >>> be useful to try it with Bacula, though. >>>=20 >>>> # mt -f /dev/nsa1 ostatus =20 >>>> Mode Density Blocksize bpi Compression >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> ---------available modes--------- >>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> --------------------------------- >>>> Current Driver State: at rest. >>>> --------------------------------- >>>> File Number: 0 Record Number: 0 Residual Count 0 >>>>=20 >>>>=20 >>>> After doing a very small tar -c and tar -x, I have: >>>>=20 >>>> # mt -f /dev/nsa1 /dev/nsa1 ostatus >>>> Mode Density Blocksize bpi Compression >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> ---------available modes--------- >>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>> --------------------------------- >>>> Current Driver State: at rest. >>>> --------------------------------- >>>> File Number: 0 Record Number: 7 Residual Count 0 >>>=20 >>> Woohoo! It works. >>>=20 >>>> # mt -f /dev/nsa1 status -v >>>> Drive: sa1: Serial Number: CXA09S1340 >>>> --------------------------------- >>>> Mode Density Blocksize bpi = Compression >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >>>> --------------------------------- >>>> Current Driver State: at rest. >>>> --------------------------------- >>>> Partition: 0 Calc File Number: 0 Calc Record Number: 7 >>>> Residual: 0 Reported File Number: -1 Reported Record Number: = -1 >>>> Flags: None >>>> --------------------------------- >>>> Tape I/O parameters: >>>> Maximum I/O size allowed by driver and controller (maxio): 65536 = bytes >>>> Maximum I/O size reported by controller (cpi_maxio): 0 bytes >>>> Maximum block size supported by tape drive and media (max_blk): = 16777214 bytes >>>> Minimum block size supported by tape drive and media (min_blk): 2 = bytes >>>> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >>>> Maximum possible I/O size (max_effective_iosize): 65536 bytes >>>>=20 >>>> I may not get to testing Bacula today. =20 >>>>=20 >>>> Based on the above, is there any commands you'd like me to try? >>>=20 >>> Aside from making sure things work okay with Bacula, that is = probably >>> sufficient. These drives won't support density reports or position >>> information. >>>=20 >>>> Read below regarding two tape drives >>>>=20 >>>>>=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 >>>> How does this affect a tape library with more than one tape drive? >>>>=20 >>>> [root@cuppy:~] # camcontrol amcontrol devlist >>>> at scbus0 target 0 lun 0 = (pass0,ch0) >>>> at scbus0 target 2 lun 0 = (sa1,pass2) >>>> at scbus1 target 0 lun 0 = (pass3,ada0) >>>> at scbus2 target 0 lun 0 = (pass4,ada1) >>>> at scbus3 target 0 lun 0 = (pass5,ses0) >>>>=20 >>>> This system has two tapes drives and I can access them through the = front panel but: >>>>=20 >>>> # ls -l /dev/*sa* >>>> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 >>>> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 >>>> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 >>>> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl >>>>=20 >>>> ... only one tape drives shows up. >>>=20 >>>=20 >>> Hmm. The tape drive is listed as sa1, which implies that there may = be an >>> sa0 that was there previously or is in the process of probing. What = does >>> dmesg show? How about 'camcontrol devlist -v'? >>=20 >> # camcontrol devlist -v >> scbus0 on ahc0 bus 0: >> at scbus0 target 0 lun 0 = (pass0,ch0) >> at scbus0 target 2 lun 0 = (sa1,pass2) >> <> at scbus0 target -1 lun ffffffff = () >> scbus1 on ahcich2 bus 0: >> at scbus1 target 0 lun 0 = (pass3,ada0) >> <> at scbus1 target -1 lun ffffffff = () >> scbus2 on ahcich4 bus 0: >> at scbus2 target 0 lun 0 = (pass4,ada1) >> <> at scbus2 target -1 lun ffffffff = () >> scbus3 on ahciem0 bus 0: >> at scbus3 target 0 lun 0 = (pass5,ses0) >> <> at scbus3 target -1 lun ffffffff = () >> scbus-1 on xpt0 bus 0: >> <> at scbus-1 target -1 lun ffffffff = (xpt0) >>=20 >>=20 >> BUT! >>=20 >> # grep sa /var/run/dmesg.boot=20 >> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID >> module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error 19 >> alc0: Using 1 MSIX message(s). >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> orm0: at iomem 0xce800-0xcefff on isa0 >> atkbdc0: at port 0x60,0x64 on isa0 >> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 >> sa0: Removable Sequential Access SCSI-2 = device=20 >> sa0: Serial Number CXA22S2338 >> sa0: 10.000MB/s transfers (10.000MHz, offset 15) >> sa0: quirks=3D0x100 >> sa1 at ahc0 bus 0 scbus0 target 2 lun 0 >> sa1: Removable Sequential Access SCSI-2 = device=20 >> sa1: Serial Number CXA09S1340 >> sa1: 10.000MB/s transfers (10.000MHz, offset 15) >> sa1: quirks=3D0x100 >=20 > If you run 'dmesg', you should have seen a message when it went away. = Perhaps > there will be something preceding it that will give us a clue about = the > problem. (Generally a selection timeout.) At least this does show = that > sa0 is at target 1, and so should not conflict with the library or = sa1. Ahh: Trying to mount root from zfs:system/bootenv/FreeBSDHEad []... sa0 at ahc0 bus 0 scbus0 target 1 lun 0 sa0: s/n CXA22S2338 detached (sa0:ahc0:0:1:0): Periph destroyed arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 arp: 10.55.0.60 moved from 78:ca:39:fe:d6:b3 to e4:ce:8f:46:f1:98 on em0 (sa1:ahc0:0:2:0): 64512-byte tape record bigger than supplied buffer (sa1:ahc0:0:2:0): 10240-byte tape record bigger than supplied buffer >=20 >>>=20 >>> I would look at cabling and termination. Is this your library? >>=20 >> Yes, it is. =20 >>=20 >>>=20 >>> = http://manx.classiccmp.org/collections/mds-199909/cd3/tape/tl891uga.pdf >>>=20 >>> If it is close enough, there are 6 connectors on the back. You = would want >>> to have something plugged into all 6, either a cable or a = terminator. >>=20 >> Yes, that's mine, and yes, there's two short cables, a terminator, = and the cable to the SCSI card in my computer. >=20 > That sounds correct for a configuration with everything on one bus. >=20 >>>=20 >>> In the manual above, the SCSI IDs are set via the front panel. If = the >>> other drive is on the same bus as the drive above and the library = device, >>> it should be at a separate SCSI ID. >>=20 >> I did have the entire thing torn apart today, to extract a tape which = would not budge. >=20 > Ahh. The SCSI IDs are right, so that doesn't appear to be the issue. >=20 >>>=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 >>>>> _______________________________________________ >>>>> 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" >>>>=20 >>>> ?=20 >>>> Dan Langille >>>> http://langille.org/ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=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 Mon Mar 2 00:41:09 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 C728BB2; Mon, 2 Mar 2015 00:41:09 +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 9C8A9D17; Mon, 2 Mar 2015 00:41:09 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 8B385F6F ; Mon, 2 Mar 2015 00:41:08 +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: <20150302003150.GB71528@mithlond.kdm.org> Date: Sun, 1 Mar 2015 19:41:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@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: Mon, 02 Mar 2015 00:41:09 -0000 > On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry wrote: >=20 > On Sun, Mar 01, 2015 at 19:15:05 -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 >>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>=20 >> Device { >> Name =3D DLT >> Description =3D "QUANTUM DLT7000 1624" >> Media Type =3D DLT >> Archive Device =3D /dev/nsa1 >>=20 >> Autochanger =3D YES >> Drive Index =3D 0 >>=20 >> Offline On Unmount =3D no >> Hardware End of Medium =3D yes >> BSF at EOM =3D yes >> Backward Space Record =3D no >> Fast Forward Space File =3D no >> TWO EOF =3D yes >> } >>=20 >> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a = btape test on this same model. >>=20 >> Here's the test I ran tonight: >>=20 >> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >> Tape block granularity is 1024 bytes. >> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >> *test >>=20 >> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>=20 >> I'm going to write 10000 records and an EOF >> then write 10000 records and an EOF, then rewind, >> and re-read the data to verify that it is correct. >>=20 >> This is an *essential* feature ... >>=20 >> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1210-0 Rewind OK. >> 10000 blocks re-read correctly. >> Got EOF on tape. >> 10000 blocks re-read correctly. >> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D= >>=20 >> btape: btape.c:1277-0 Block position test >> btape: btape.c:1289-0 Rewind OK. >> Reposition to file:block 0:4 >> Block 5 re-read correctly. >> Reposition to file:block 0:200 >> Block 201 re-read correctly. >> Reposition to file:block 0:9999 >> Block 10000 re-read correctly. >> Reposition to file:block 1:0 >> Block 10001 re-read correctly. >> Reposition to file:block 1:600 >> Block 10601 re-read correctly. >> Reposition to file:block 1:9999 >> Block 20000 re-read correctly. >> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D= >>=20 >>=20 >>=20 >> =3D=3D=3D Append files test =3D=3D=3D >>=20 >> This test is essential to Bacula. >>=20 >> I'm going to write one record in file 0, >> two records in file 1, >> and three records in file 2 >>=20 >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1420-0 Now moving to end of medium. >=20 > This is the critical piece. The test moves the tape to the end of the > medium. With hardware position information, you can tell what = filemark > you're on. Without it, you can't. >=20 >> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" = (/dev/nsa1). ERR=3DNo error: 0. >> We should be in file 3. I am at file 0. This is NOT correct!!!! >>=20 >> Append test failed. Attempting again. >> Setting "Hardware End of Medium =3D no >> and "Fast Forward Space File =3D no >> and retrying append test. >=20 > This is not surprsing, given that the drive doesn't support long read > position data. (It's a SCSI-2 device.) So that means that Bacula = will > need to do it manually. Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that tape library is hooked up to a different computer and was doing backups = today. > =3D=3D=3D Append files test =3D=3D=3D >>=20 >> This test is essential to Bacula. >>=20 >> I'm going to write one record in file 0, >> two records in file 1, >> and three records in file 2 >>=20 >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1420-0 Now moving to end of medium. >> btape: btape.c:625-0 Moved to end of medium. >> We should be in file 3. I am at file 3. This is correct! >>=20 >> Now the important part, I am going to attempt to append to the tape. >>=20 >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> Done appending, there should be no I/O errors >>=20 >> Doing Bacula scan of blocks: >> 1 block of 64448 bytes in file 1 >> End of File mark. >> 2 blocks of 64448 bytes in file 2 >> End of File mark. >> 3 blocks of 64448 bytes in file 3 >> End of File mark. >> 1 block of 64448 bytes in file 4 >> End of File mark. >> Total files=3D4, blocks=3D7, bytes =3D 451,136 >> End scanning the tape. >> We should be in file 4. I am at file 4. This is correct! >>=20 >>=20 >> It looks like the test worked this time, please add: >>=20 >> Hardware End of Medium =3D No >>=20 >> Fast Forward Space File =3D No >> to your Device resource in the Storage conf file. >>=20 >> The above Bacula scan should have output identical to what follows. >> Please double check it ... >> =3D=3D=3D Sample correct output =3D=3D=3D >> 1 block of 64448 bytes in file 1 >> End of File mark. >> 2 blocks of 64448 bytes in file 2 >> End of File mark. >> 3 blocks of 64448 bytes in file 3 >> End of File mark. >> 1 block of 64448 bytes in file 4 >> End of File mark. >> Total files=3D4, blocks=3D7, bytes =3D 451,136 >> =3D=3D=3D End sample correct output =3D=3D=3D >>=20 >> If the above scan output is not identical to the >> sample output, you MUST correct the problem >> or Bacula will not be able to write multiple Jobs to=20 >> the tape. >>=20 >> Skipping read backwards test because BSR turned off. >>=20 >>=20 >> =3D=3D=3D Forward space files test =3D=3D=3D >>=20 >> This test is essential to Bacula. >>=20 >> I'm going to write five files then test forward spacing >>=20 >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >> btape: btape.c:1909-0 Wrote block to device. >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1634-0 Now forward spacing 1 file. >> We should be in file 1. I am at file 1. This is correct! >> btape: btape.c:1646-0 Now forward spacing 2 files. >> We should be in file 3. I am at file 3. This is correct! >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1659-0 Now forward spacing 4 files. >> We should be in file 4. I am at file 4. This is correct! >>=20 >> btape: btape.c:1677-0 Now forward spacing 1 more file. >> We should be in file 5. I am at file 5. This is correct! >>=20 >> =3D=3D=3D End Forward space files test =3D=3D=3D >>=20 >>=20 >> Ah, I see you have an autochanger configured. >> To test the autochanger you must have a blank tape >> that I can write on in Slot 1. >>=20 >> Do you wish to continue with the Autochanger test? (y/n): y >>=20 >>=20 >> =3D=3D=3D Autochanger test =3D=3D=3D >>=20 >> 3301 Issuing autochanger "loaded" command. >> Nothing loaded in the drive. OK. >> 3303 Issuing autochanger "load 1 0" command. >> 3303 Autochanger "load 1 0" status is OK. >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >> btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) >> btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) >>=20 >> The test autochanger worked!! >=20 > Great, thanks for running the test! Looks like things are working as = well > as they were before. >=20 >>>=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 >> Errors are interesting to me. Especially corrected errors. They are = a good indicator of tape quality. >>=20 >=20 > Yes. At least on modern drives, there is a good bit available in the = log > pages. You can try seeing what logs your drive supports by installing = the > sg3_utils package and running 'sg_logs sa1 --all'. >=20 > Given the large amount of data available on some drives, and the = difficulty > distilling it down to a clear good/bad, I probably won't stick that in = the > 'mt status' output. >=20 > But you can certainly take a look at it and have an idea of whether = your > particular tape/drive are experiencing issues. That's a lot of output: = https://gist.github.com/dlangille/0e15a7fbf7acab56fd32 I will run some Bacula jobs soon. I'm still setting up config files. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 02:06:13 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 E8976DD1; Mon, 2 Mar 2015 02:06:13 +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 83D387FE; Mon, 2 Mar 2015 02:06:13 +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 t22269Sv073476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Mar 2015 19:06:09 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22268O8073475; Sun, 1 Mar 2015 19:06:08 -0700 (MST) (envelope-from ken) Date: Sun, 1 Mar 2015 19:06:08 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302020608.GA73433@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> <20150302003658.GA72258@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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]); Sun, 01 Mar 2015 19:06:10 -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: Mon, 02 Mar 2015 02:06:14 -0000 On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry wrote: > > > > On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: > >> > >>> On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry wrote: > >>> > >>> On Sun, Mar 01, 2015 at 17:06:24 -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. > >>>>> > >>>>> ============ > >>>>> Rough draft commit message: > >>>>> > >>>>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt > >>>>> > >>>>> The patches against FreeBSD/head as of SVN revision 278706: > >>>>> > >>>>> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt > >>>>> > >>>>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. > >>>>> > >>>>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt > >>>>> ============ > >>>>> > >>>>> The intent is to get the tape infrastructure more up to date, so we can > >>>>> support LTFS and more modern tape drives: > >>>>> > >>>>> http://www.ibm.com/systems/storage/tape/ltfs/ > >>>>> > >>>>> 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. > >>>>> > >>>>> The commit message below outlines most of the changes. > >>>>> > >>>>> A few comments: > >>>>> > >>>>> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. > >>>>> > >>>>> 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. > >>>>> > >>>>> 3. I have tested with a reasonable amount of tape hardware (see below for a > >>>>> list), but more testing and feedback would be good. > >>>>> > >>>>> 4. Standard 'mt status' output looks like this: > >>>>> > >>>>> # 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 > >>>>> > >>>>> 5. 'mt status -v' looks like this: > >>>>> > >>>>> # 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 > >>>> > >>>> > >>>> # mtx -f /dev/pass0 status > >>>> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) > >>>> Data Transfer Element 0:Empty > >>>> Data Transfer Element 1:Empty > >>>> Storage Element 1:Empty > >>>> Storage Element 2:Empty > >>>> Storage Element 3:Empty > >>>> Storage Element 4:Full :VolumeTag=FAI260 > >>>> Storage Element 5:Full :VolumeTag=FAI261 > >>>> Storage Element 6:Full :VolumeTag=FAI262 > >>>> Storage Element 7:Full :VolumeTag=FAI263 > >>>> Storage Element 8:Empty > >>>> Storage Element 9:Empty > >>>> Storage Element 10:Empty > >>>> > >>>> > >>>> It was at this point I spent the next 90 minute trying to get the tape > >>>> drive out of the tape library to free a stuck tape. Some of this was spent > >>>> attempting, and failing, to undo a stripped screw. I stopped the attempt when > >>>> I noticed the screw did need to be removed. :/ > >>> > >>> Thanks for all of the effort! Looks like it is paying off! :) > >>> > >>>> When I do this command, I hear the drive move a bit, to read the tape: > >>>> > >>>> # mt -f /dev/nsa1 status > >>>> Drive: sa1: Serial Number: CXA09S1340 > >>>> --------------------------------- > >>>> Mode Density Blocksize bpi Compression > >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >>>> --------------------------------- > >>>> Current Driver State: at rest. > >>>> --------------------------------- > >>>> Partition: 0 Calc File Number: 0 Calc Record Number: 0 > >>>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >>>> Flags: None > >>> > >>> Looks like the drive isn't reporting position information. It will still > >>> be useful to try it with Bacula, though. > >>> > >>>> # mt -f /dev/nsa1 ostatus > >>>> Mode Density Blocksize bpi Compression > >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> ---------available modes--------- > >>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> --------------------------------- > >>>> Current Driver State: at rest. > >>>> --------------------------------- > >>>> File Number: 0 Record Number: 0 Residual Count 0 > >>>> > >>>> > >>>> After doing a very small tar -c and tar -x, I have: > >>>> > >>>> # mt -f /dev/nsa1 /dev/nsa1 ostatus > >>>> Mode Density Blocksize bpi Compression > >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> ---------available modes--------- > >>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>> --------------------------------- > >>>> Current Driver State: at rest. > >>>> --------------------------------- > >>>> File Number: 0 Record Number: 7 Residual Count 0 > >>> > >>> Woohoo! It works. > >>> > >>>> # mt -f /dev/nsa1 status -v > >>>> Drive: sa1: Serial Number: CXA09S1340 > >>>> --------------------------------- > >>>> Mode Density Blocksize bpi Compression > >>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >>>> --------------------------------- > >>>> Current Driver State: at rest. > >>>> --------------------------------- > >>>> Partition: 0 Calc File Number: 0 Calc Record Number: 7 > >>>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >>>> Flags: None > >>>> --------------------------------- > >>>> Tape I/O parameters: > >>>> Maximum I/O size allowed by driver and controller (maxio): 65536 bytes > >>>> Maximum I/O size reported by controller (cpi_maxio): 0 bytes > >>>> Maximum block size supported by tape drive and media (max_blk): 16777214 bytes > >>>> Minimum block size supported by tape drive and media (min_blk): 2 bytes > >>>> Block granularity supported by tape drive and media (blk_gran): 0 bytes > >>>> Maximum possible I/O size (max_effective_iosize): 65536 bytes > >>>> > >>>> I may not get to testing Bacula today. > >>>> > >>>> Based on the above, is there any commands you'd like me to try? > >>> > >>> Aside from making sure things work okay with Bacula, that is probably > >>> sufficient. These drives won't support density reports or position > >>> information. > >>> > >>>> Read below regarding two tape drives > >>>> > >>>>> > >>>>> 6. Existing applications should work without changes. If not, please let > >>>>> me know. Hopefully they will move over time to the new interfaces. > >>>>> > >>>>> 7. There are lots of additional features that could be added later. > >>>>> Append-only support, encryption, more log pages, etc. > >>>>> > >>>>> 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 > >>>>> to the status XML from the sa(4) driver. > >>>>> > >>>>> ============ > >>>>> Significant upgrades to sa(4) and mt(1). > >>>>> > >>>>> 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. > >>>>> > >>>>> Significant changes and new features include: > >>>>> > >>>>> 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. > >>>>> > >>>>> 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. > >>>>> > >>>>> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. > >>>> > >>>> How does this affect a tape library with more than one tape drive? > >>>> > >>>> [root@cuppy:~] # camcontrol amcontrol devlist > >>>> at scbus0 target 0 lun 0 (pass0,ch0) > >>>> at scbus0 target 2 lun 0 (sa1,pass2) > >>>> at scbus1 target 0 lun 0 (pass3,ada0) > >>>> at scbus2 target 0 lun 0 (pass4,ada1) > >>>> at scbus3 target 0 lun 0 (pass5,ses0) > >>>> > >>>> This system has two tapes drives and I can access them through the front panel but: > >>>> > >>>> # ls -l /dev/*sa* > >>>> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 > >>>> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 > >>>> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 > >>>> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl > >>>> > >>>> ... only one tape drives shows up. > >>> > >>> > >>> Hmm. The tape drive is listed as sa1, which implies that there may be an > >>> sa0 that was there previously or is in the process of probing. What does > >>> dmesg show? How about 'camcontrol devlist -v'? > >> > >> # camcontrol devlist -v > >> scbus0 on ahc0 bus 0: > >> at scbus0 target 0 lun 0 (pass0,ch0) > >> at scbus0 target 2 lun 0 (sa1,pass2) > >> <> at scbus0 target -1 lun ffffffff () > >> scbus1 on ahcich2 bus 0: > >> at scbus1 target 0 lun 0 (pass3,ada0) > >> <> at scbus1 target -1 lun ffffffff () > >> scbus2 on ahcich4 bus 0: > >> at scbus2 target 0 lun 0 (pass4,ada1) > >> <> at scbus2 target -1 lun ffffffff () > >> scbus3 on ahciem0 bus 0: > >> at scbus3 target 0 lun 0 (pass5,ses0) > >> <> at scbus3 target -1 lun ffffffff () > >> scbus-1 on xpt0 bus 0: > >> <> at scbus-1 target -1 lun ffffffff (xpt0) > >> > >> > >> BUT! > >> > >> # grep sa /var/run/dmesg.boot > >> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID > >> module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error 19 > >> alc0: Using 1 MSIX message(s). > >> isab0: at device 31.0 on pci0 > >> isa0: on isab0 > >> orm0: at iomem 0xce800-0xcefff on isa0 > >> atkbdc0: at port 0x60,0x64 on isa0 > >> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > >> sa0: Removable Sequential Access SCSI-2 device > >> sa0: Serial Number CXA22S2338 > >> sa0: 10.000MB/s transfers (10.000MHz, offset 15) > >> sa0: quirks=0x100 > >> sa1 at ahc0 bus 0 scbus0 target 2 lun 0 > >> sa1: Removable Sequential Access SCSI-2 device > >> sa1: Serial Number CXA09S1340 > >> sa1: 10.000MB/s transfers (10.000MHz, offset 15) > >> sa1: quirks=0x100 > > > > If you run 'dmesg', you should have seen a message when it went away. Perhaps > > there will be something preceding it that will give us a clue about the > > problem. (Generally a selection timeout.) At least this does show that > > sa0 is at target 1, and so should not conflict with the library or sa1. > > Ahh: > > Trying to mount root from zfs:system/bootenv/FreeBSDHEad []... > sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > sa0: s/n CXA22S2338 detached > (sa0:ahc0:0:1:0): Periph destroyed > arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 > arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 > arp: 10.55.0.60 moved from 78:ca:39:fe:d6:b3 to e4:ce:8f:46:f1:98 on em0 > (sa1:ahc0:0:2:0): 64512-byte tape record bigger than supplied buffer > (sa1:ahc0:0:2:0): 10240-byte tape record bigger than supplied buffer Okay. Well, no indication of what happened. Perhaps boot -v will show it, perhaps not. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 02:30: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 9658754C; Mon, 2 Mar 2015 02:30:01 +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 419149A8; Mon, 2 Mar 2015 02:30:00 +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 t222Tw6M073775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 1 Mar 2015 19:29:58 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t222Tvde073774; Sun, 1 Mar 2015 19:29:57 -0700 (MST) (envelope-from ken) Date: Sun, 1 Mar 2015 19:29:57 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302022957.GB73433@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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]); Sun, 01 Mar 2015 19:29:58 -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: Mon, 02 Mar 2015 02:30:01 -0000 On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry wrote: > > > > On Sun, Mar 01, 2015 at 19:15:05 -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. > >>> > >>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf > >> > >> Device { > >> Name = DLT > >> Description = "QUANTUM DLT7000 1624" > >> Media Type = DLT > >> Archive Device = /dev/nsa1 > >> > >> Autochanger = YES > >> Drive Index = 0 > >> > >> Offline On Unmount = no > >> Hardware End of Medium = yes > >> BSF at EOM = yes > >> Backward Space Record = no > >> Fast Forward Space File = no > >> TWO EOF = yes > >> } > >> > >> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model. > >> > >> Here's the test I ran tonight: > >> > >> [root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 > >> Tape block granularity is 1024 bytes. > >> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. > >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >> *test > >> > >> === Write, rewind, and re-read test === > >> > >> I'm going to write 10000 records and an EOF > >> then write 10000 records and an EOF, then rewind, > >> and re-read the data to verify that it is correct. > >> > >> This is an *essential* feature ... > >> > >> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1210-0 Rewind OK. > >> 10000 blocks re-read correctly. > >> Got EOF on tape. > >> 10000 blocks re-read correctly. > >> === Test Succeeded. End Write, rewind, and re-read test === > >> > >> btape: btape.c:1277-0 Block position test > >> btape: btape.c:1289-0 Rewind OK. > >> Reposition to file:block 0:4 > >> Block 5 re-read correctly. > >> Reposition to file:block 0:200 > >> Block 201 re-read correctly. > >> Reposition to file:block 0:9999 > >> Block 10000 re-read correctly. > >> Reposition to file:block 1:0 > >> Block 10001 re-read correctly. > >> Reposition to file:block 1:600 > >> Block 10601 re-read correctly. > >> Reposition to file:block 1:9999 > >> Block 20000 re-read correctly. > >> === Test Succeeded. End Write, rewind, and re-read test === > >> > >> > >> > >> === Append files test === > >> > >> This test is essential to Bacula. > >> > >> I'm going to write one record in file 0, > >> two records in file 1, > >> and three records in file 2 > >> > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1420-0 Now moving to end of medium. > > > > This is the critical piece. The test moves the tape to the end of the > > medium. With hardware position information, you can tell what filemark > > you're on. Without it, you can't. > > > >> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0. > >> We should be in file 3. I am at file 0. This is NOT correct!!!! > >> > >> Append test failed. Attempting again. > >> Setting "Hardware End of Medium = no > >> and "Fast Forward Space File = no > >> and retrying append test. > > > > This is not surprsing, given that the drive doesn't support long read > > position data. (It's a SCSI-2 device.) So that means that Bacula will > > need to do it manually. > > Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that > tape library is hooked up to a different computer and was doing backups today. So, here is one thing that we can try to see whether these drives support long position information, even though they only claim to be SCSI-2. If they do, we can potentially add a quirk (or autodetection) to enable it. The code currently doesn't bother asking drives that claim to be SCSI-2 for long position information. (Because that feature was added in the SSC spec, which came after SCSI-2.) Issue a READ POSITION with the short form specified: camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd Issue a READ POSITION with the vendor-specific block numbers: camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd Issue a READ POSITION with the long form data: camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd If it supports the last one, then I can put a quirk (or autodetection) in the driver and Bacula will get the hardware filemarks. You should try this on your SDLT as well. It may well support it. Google didn't quickly produce a SCSI manual for the DEC drive, but the Quantum SDLT manual indicates that it supports long position data, despite identifying itself as a SCSI-2 drive. > > === Append files test === > >> > >> This test is essential to Bacula. > >> > >> I'm going to write one record in file 0, > >> two records in file 1, > >> and three records in file 2 > >> > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1420-0 Now moving to end of medium. > >> btape: btape.c:625-0 Moved to end of medium. > >> We should be in file 3. I am at file 3. This is correct! > >> > >> Now the important part, I am going to attempt to append to the tape. > >> > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> Done appending, there should be no I/O errors > >> > >> Doing Bacula scan of blocks: > >> 1 block of 64448 bytes in file 1 > >> End of File mark. > >> 2 blocks of 64448 bytes in file 2 > >> End of File mark. > >> 3 blocks of 64448 bytes in file 3 > >> End of File mark. > >> 1 block of 64448 bytes in file 4 > >> End of File mark. > >> Total files=4, blocks=7, bytes = 451,136 > >> End scanning the tape. > >> We should be in file 4. I am at file 4. This is correct! > >> > >> > >> It looks like the test worked this time, please add: > >> > >> Hardware End of Medium = No > >> > >> Fast Forward Space File = No > >> to your Device resource in the Storage conf file. > >> > >> The above Bacula scan should have output identical to what follows. > >> Please double check it ... > >> === Sample correct output === > >> 1 block of 64448 bytes in file 1 > >> End of File mark. > >> 2 blocks of 64448 bytes in file 2 > >> End of File mark. > >> 3 blocks of 64448 bytes in file 3 > >> End of File mark. > >> 1 block of 64448 bytes in file 4 > >> End of File mark. > >> Total files=4, blocks=7, bytes = 451,136 > >> === End sample correct output === > >> > >> If the above scan output is not identical to the > >> sample output, you MUST correct the problem > >> or Bacula will not be able to write multiple Jobs to > >> the tape. > >> > >> Skipping read backwards test because BSR turned off. > >> > >> > >> === Forward space files test === > >> > >> This test is essential to Bacula. > >> > >> I'm going to write five files then test forward spacing > >> > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >> btape: btape.c:1909-0 Wrote block to device. > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1634-0 Now forward spacing 1 file. > >> We should be in file 1. I am at file 1. This is correct! > >> btape: btape.c:1646-0 Now forward spacing 2 files. > >> We should be in file 3. I am at file 3. This is correct! > >> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1659-0 Now forward spacing 4 files. > >> We should be in file 4. I am at file 4. This is correct! > >> > >> btape: btape.c:1677-0 Now forward spacing 1 more file. > >> We should be in file 5. I am at file 5. This is correct! > >> > >> === End Forward space files test === > >> > >> > >> Ah, I see you have an autochanger configured. > >> To test the autochanger you must have a blank tape > >> that I can write on in Slot 1. > >> > >> Do you wish to continue with the Autochanger test? (y/n): y > >> > >> > >> === Autochanger test === > >> > >> 3301 Issuing autochanger "loaded" command. > >> Nothing loaded in the drive. OK. > >> 3303 Issuing autochanger "load 1 0" command. > >> 3303 Autochanger "load 1 0" status is OK. > >> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >> btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) > >> btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) > >> > >> The test autochanger worked!! > > > > Great, thanks for running the test! Looks like things are working as well > > as they were before. > > > >>> > >>>> 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.) > >> > >> Errors are interesting to me. Especially corrected errors. They are a good indicator of tape quality. > >> > > > > Yes. At least on modern drives, there is a good bit available in the log > > pages. You can try seeing what logs your drive supports by installing the > > sg3_utils package and running 'sg_logs sa1 --all'. > > > > Given the large amount of data available on some drives, and the difficulty > > distilling it down to a clear good/bad, I probably won't stick that in the > > 'mt status' output. > > > > But you can certainly take a look at it and have an idea of whether your > > particular tape/drive are experiencing issues. > > That's a lot of output: https://gist.github.com/dlangille/0e15a7fbf7acab56fd32 That is a lot. > I will run some Bacula jobs soon. I'm still setting up config files. Thanks for all the testing, I really appreciate it! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 07:49:58 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 EF87C42C for ; Mon, 2 Mar 2015 07:49:58 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (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 B3C52AF3 for ; Mon, 2 Mar 2015 07:49:58 +0000 (UTC) Received: by igjz20 with SMTP id z20so15029341igj.4 for ; Sun, 01 Mar 2015 23:49:58 -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=y3pmBx03iisa1XmEm5TdDYp+gNulKsmAA3n6CKH6u9M=; b=xaj09fuGNtSTWV5Zrc2wso/Rg3ZjFiy/FD6SHe8itsRqNwvSe8/tQrNi2mw8XRnm1o 1v0eA+dk1r65bHii6oIctgQy+ZPXNiBY7ztcGiGiiJYH1yXoia2jzX4V8axOz1qHim1u pdvOQJlEyk0WaXGT/C1C6z7SqguW+zlLccSvx41CerJ79Xxt0JTWEx2wW64ez+Xrkzdb DH/yI2jMw4LRAJSVfG2C3pqBR4hyb9Ua6VyHRuO09Lr6KMQ12xinfnpzduzJl4Yitdjt sXtpeGGZot5z6RcBH7AulGsxCZcBn8SBFXDjE8GSED3Lsh5h0UbO1dy76hAuhF4GHEEx whvg== MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr20392680igl.6.1425282598001; Sun, 01 Mar 2015 23:49:58 -0800 (PST) Received: by 10.36.23.133 with HTTP; Sun, 1 Mar 2015 23:49:57 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 15:49:57 +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: Mon, 02 Mar 2015 07:49:59 -0000 Hi, I found the related code in the function sym_int_sir: /* * The device wants us to tranfer more data than * expected or in the wrong direction. * The number of extra bytes is in scratcha. * It is a data overrun condition. */ case *SIR_DATA_OVERRUN*: if (cp) { OUTONB (HF_PRT, HF_EXT_ERR); * cp->xerr_status |= XE_EXTRA_DATA;* cp->extra_bytes += INL (nc_scratcha); } goto out; I'm not familiar with SCSI. What does DATA_OVERRUN actually mean? How can it be triggered? Could you give more details about it? Thanks for your help. Br. Yafeng On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: > 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 Mon Mar 2 16:10:00 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 1E742516; Mon, 2 Mar 2015 16:10:00 +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 BC9D1C22; Mon, 2 Mar 2015 16:09:59 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 2AC1F6D7E ; Mon, 2 Mar 2015 16:09:58 +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: <20150302022957.GB73433@mithlond.kdm.org> Date: Mon, 2 Mar 2015 11:09:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@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: Mon, 02 Mar 2015 16:10:00 -0000 > On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry wrote: >=20 > On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>=20 >>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>=20 >>>> Device { >>>> Name =3D DLT >>>> Description =3D "QUANTUM DLT7000 1624" >>>> Media Type =3D DLT >>>> Archive Device =3D /dev/nsa1 >>>>=20 >>>> Autochanger =3D YES >>>> Drive Index =3D 0 >>>>=20 >>>> Offline On Unmount =3D no >>>> Hardware End of Medium =3D yes >>>> BSF at EOM =3D yes >>>> Backward Space Record =3D no >>>> Fast Forward Space File =3D no >>>> TWO EOF =3D yes >>>> } >>>>=20 >>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has = a btape test on this same model. >>>>=20 >>>> Here's the test I ran tonight: >>>>=20 >>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>> Tape block granularity is 1024 bytes. >>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>> *test >>>>=20 >>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>=20 >>>> I'm going to write 10000 records and an EOF >>>> then write 10000 records and an EOF, then rewind, >>>> and re-read the data to verify that it is correct. >>>>=20 >>>> This is an *essential* feature ... >>>>=20 >>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1210-0 Rewind OK. >>>> 10000 blocks re-read correctly. >>>> Got EOF on tape. >>>> 10000 blocks re-read correctly. >>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D= >>>>=20 >>>> btape: btape.c:1277-0 Block position test >>>> btape: btape.c:1289-0 Rewind OK. >>>> Reposition to file:block 0:4 >>>> Block 5 re-read correctly. >>>> Reposition to file:block 0:200 >>>> Block 201 re-read correctly. >>>> Reposition to file:block 0:9999 >>>> Block 10000 re-read correctly. >>>> Reposition to file:block 1:0 >>>> Block 10001 re-read correctly. >>>> Reposition to file:block 1:600 >>>> Block 10601 re-read correctly. >>>> Reposition to file:block 1:9999 >>>> Block 20000 re-read correctly. >>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D=3D= >>>>=20 >>>>=20 >>>>=20 >>>> =3D=3D=3D Append files test =3D=3D=3D >>>>=20 >>>> This test is essential to Bacula. >>>>=20 >>>> I'm going to write one record in file 0, >>>> two records in file 1, >>>> and three records in file 2 >>>>=20 >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1420-0 Now moving to end of medium. >>>=20 >>> This is the critical piece. The test moves the tape to the end of = the >>> medium. With hardware position information, you can tell what = filemark >>> you're on. Without it, you can't. >>>=20 >>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" = (/dev/nsa1). ERR=3DNo error: 0. >>>> We should be in file 3. I am at file 0. This is NOT correct!!!! >>>>=20 >>>> Append test failed. Attempting again. >>>> Setting "Hardware End of Medium =3D no >>>> and "Fast Forward Space File =3D no >>>> and retrying append test. >>>=20 >>> This is not surprsing, given that the drive doesn't support long = read >>> position data. (It's a SCSI-2 device.) So that means that Bacula = will >>> need to do it manually. >>=20 >> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but = that >> tape library is hooked up to a different computer and was doing = backups today. >=20 > So, here is one thing that we can try to see whether these drives = support > long position information, even though they only claim to be SCSI-2. = If > they do, we can potentially add a quirk (or autodetection) to enable = it. > The code currently doesn't bother asking drives that claim to be = SCSI-2 > for long position information. (Because that feature was added in the > SSC spec, which came after SCSI-2.) >=20 > Issue a READ POSITION with the short form specified: >=20 > camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >=20 > Issue a READ POSITION with the vendor-specific block numbers: >=20 > camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >=20 > Issue a READ POSITION with the long form data: >=20 > camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >=20 > If it supports the last one, then I can put a quirk (or autodetection) = in > the driver and Bacula will get the hardware filemarks. You should try = this > on your SDLT as well. It may well support it. Sadly, no: [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - = |hd 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000010 00 00 00 00 |....| 00000014 [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - = |hd 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000010 00 00 00 00 |....| 00000014 [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - = |hd camcontrol: error sending command (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00=20 (pass2:ahc0:0:2:0): CAM status: SCSI Status Error (pass2:ahc0:0:2:0): SCSI status: Check Condition (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field = in CDB) (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid [root@cuppy:~] #=20 The SDLT server is on 9.3 though: [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 = 0" -i 20 - |hd camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or sa1 doesn't exist [root@knew:/usr/home/dan] # uname -a FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0: = Tue Feb 24 21:28:03 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [root@knew:/usr/home/dan] #=20 It took me a while to figure that out... there is no sa1 on *this* = system. But, my SDLT: [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 0 0 = 0" -i 20 - |hd 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000010 00 00 00 00 |....| 00000014 [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 0 0 = 0" -i 20 - |hd 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000010 00 00 00 00 |....| 00000014 [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 0 0 = 0" -i 32 - |hd 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| 00000020 [root@knew:/usr/home/dan] #=20 >=20 > Google didn't quickly produce a SCSI manual for the DEC drive, but the > Quantum SDLT manual indicates that it supports long position data, = despite > identifying itself as a SCSI-2 drive. >=20 >>> =3D=3D=3D Append files test =3D=3D=3D >>>>=20 >>>> This test is essential to Bacula. >>>>=20 >>>> I'm going to write one record in file 0, >>>> two records in file 1, >>>> and three records in file 2 >>>>=20 >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1420-0 Now moving to end of medium. >>>> btape: btape.c:625-0 Moved to end of medium. >>>> We should be in file 3. I am at file 3. This is correct! >>>>=20 >>>> Now the important part, I am going to attempt to append to the = tape. >>>>=20 >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> Done appending, there should be no I/O errors >>>>=20 >>>> Doing Bacula scan of blocks: >>>> 1 block of 64448 bytes in file 1 >>>> End of File mark. >>>> 2 blocks of 64448 bytes in file 2 >>>> End of File mark. >>>> 3 blocks of 64448 bytes in file 3 >>>> End of File mark. >>>> 1 block of 64448 bytes in file 4 >>>> End of File mark. >>>> Total files=3D4, blocks=3D7, bytes =3D 451,136 >>>> End scanning the tape. >>>> We should be in file 4. I am at file 4. This is correct! >>>>=20 >>>>=20 >>>> It looks like the test worked this time, please add: >>>>=20 >>>> Hardware End of Medium =3D No >>>>=20 >>>> Fast Forward Space File =3D No >>>> to your Device resource in the Storage conf file. >>>>=20 >>>> The above Bacula scan should have output identical to what follows. >>>> Please double check it ... >>>> =3D=3D=3D Sample correct output =3D=3D=3D >>>> 1 block of 64448 bytes in file 1 >>>> End of File mark. >>>> 2 blocks of 64448 bytes in file 2 >>>> End of File mark. >>>> 3 blocks of 64448 bytes in file 3 >>>> End of File mark. >>>> 1 block of 64448 bytes in file 4 >>>> End of File mark. >>>> Total files=3D4, blocks=3D7, bytes =3D 451,136 >>>> =3D=3D=3D End sample correct output =3D=3D=3D >>>>=20 >>>> If the above scan output is not identical to the >>>> sample output, you MUST correct the problem >>>> or Bacula will not be able to write multiple Jobs to=20 >>>> the tape. >>>>=20 >>>> Skipping read backwards test because BSR turned off. >>>>=20 >>>>=20 >>>> =3D=3D=3D Forward space files test =3D=3D=3D >>>>=20 >>>> This test is essential to Bacula. >>>>=20 >>>> I'm going to write five files then test forward spacing >>>>=20 >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>> btape: btape.c:1909-0 Wrote block to device. >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1634-0 Now forward spacing 1 file. >>>> We should be in file 1. I am at file 1. This is correct! >>>> btape: btape.c:1646-0 Now forward spacing 2 files. >>>> We should be in file 3. I am at file 3. This is correct! >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1659-0 Now forward spacing 4 files. >>>> We should be in file 4. I am at file 4. This is correct! >>>>=20 >>>> btape: btape.c:1677-0 Now forward spacing 1 more file. >>>> We should be in file 5. I am at file 5. This is correct! >>>>=20 >>>> =3D=3D=3D End Forward space files test =3D=3D=3D >>>>=20 >>>>=20 >>>> Ah, I see you have an autochanger configured. >>>> To test the autochanger you must have a blank tape >>>> that I can write on in Slot 1. >>>>=20 >>>> Do you wish to continue with the Autochanger test? (y/n): y >>>>=20 >>>>=20 >>>> =3D=3D=3D Autochanger test =3D=3D=3D >>>>=20 >>>> 3301 Issuing autochanger "loaded" command. >>>> Nothing loaded in the drive. OK. >>>> 3303 Issuing autochanger "load 1 0" command. >>>> 3303 Autochanger "load 1 0" status is OK. >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>> btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) >>>> btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) >>>>=20 >>>> The test autochanger worked!! >>>=20 >>> Great, thanks for running the test! Looks like things are working = as well >>> as they were before. >>>=20 >>>>>=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 >>>> Errors are interesting to me. Especially corrected errors. They = are a good indicator of tape quality. >>>>=20 >>>=20 >>> Yes. At least on modern drives, there is a good bit available in = the log >>> pages. You can try seeing what logs your drive supports by = installing the >>> sg3_utils package and running 'sg_logs sa1 --all'. >>>=20 >>> Given the large amount of data available on some drives, and the = difficulty >>> distilling it down to a clear good/bad, I probably won't stick that = in the >>> 'mt status' output. >>>=20 >>> But you can certainly take a look at it and have an idea of whether = your >>> particular tape/drive are experiencing issues. >>=20 >> That's a lot of output: = https://gist.github.com/dlangille/0e15a7fbf7acab56fd32 >=20 > That is a lot. >=20 >> I will run some Bacula jobs soon. I'm still setting up config files. >=20 > Thanks for all the testing, I really appreciate it! >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 16:31: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 75ADD8B8; Mon, 2 Mar 2015 16:31:52 +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 01E28ED4; Mon, 2 Mar 2015 16:31:51 +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 t22GVl4f085578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 09:31:47 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22GVkpb085577; Mon, 2 Mar 2015 09:31:46 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 09:31:46 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302163146.GA85515@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@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]); Mon, 02 Mar 2015 09:31:47 -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: Mon, 02 Mar 2015 16:31:52 -0000 On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry wrote: > > > > On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: > >> > >>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry wrote: > >>> > >>> On Sun, Mar 01, 2015 at 19:15:05 -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. > >>>>> > >>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf > >>>> > >>>> Device { > >>>> Name = DLT > >>>> Description = "QUANTUM DLT7000 1624" > >>>> Media Type = DLT > >>>> Archive Device = /dev/nsa1 > >>>> > >>>> Autochanger = YES > >>>> Drive Index = 0 > >>>> > >>>> Offline On Unmount = no > >>>> Hardware End of Medium = yes > >>>> BSF at EOM = yes > >>>> Backward Space Record = no > >>>> Fast Forward Space File = no > >>>> TWO EOF = yes > >>>> } > >>>> > >>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model. > >>>> > >>>> Here's the test I ran tonight: > >>>> > >>>> [root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 > >>>> Tape block granularity is 1024 bytes. > >>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. > >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>> *test > >>>> > >>>> === Write, rewind, and re-read test === > >>>> > >>>> I'm going to write 10000 records and an EOF > >>>> then write 10000 records and an EOF, then rewind, > >>>> and re-read the data to verify that it is correct. > >>>> > >>>> This is an *essential* feature ... > >>>> > >>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1210-0 Rewind OK. > >>>> 10000 blocks re-read correctly. > >>>> Got EOF on tape. > >>>> 10000 blocks re-read correctly. > >>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>> > >>>> btape: btape.c:1277-0 Block position test > >>>> btape: btape.c:1289-0 Rewind OK. > >>>> Reposition to file:block 0:4 > >>>> Block 5 re-read correctly. > >>>> Reposition to file:block 0:200 > >>>> Block 201 re-read correctly. > >>>> Reposition to file:block 0:9999 > >>>> Block 10000 re-read correctly. > >>>> Reposition to file:block 1:0 > >>>> Block 10001 re-read correctly. > >>>> Reposition to file:block 1:600 > >>>> Block 10601 re-read correctly. > >>>> Reposition to file:block 1:9999 > >>>> Block 20000 re-read correctly. > >>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>> > >>>> > >>>> > >>>> === Append files test === > >>>> > >>>> This test is essential to Bacula. > >>>> > >>>> I'm going to write one record in file 0, > >>>> two records in file 1, > >>>> and three records in file 2 > >>>> > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1420-0 Now moving to end of medium. > >>> > >>> This is the critical piece. The test moves the tape to the end of the > >>> medium. With hardware position information, you can tell what filemark > >>> you're on. Without it, you can't. > >>> > >>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0. > >>>> We should be in file 3. I am at file 0. This is NOT correct!!!! > >>>> > >>>> Append test failed. Attempting again. > >>>> Setting "Hardware End of Medium = no > >>>> and "Fast Forward Space File = no > >>>> and retrying append test. > >>> > >>> This is not surprsing, given that the drive doesn't support long read > >>> position data. (It's a SCSI-2 device.) So that means that Bacula will > >>> need to do it manually. > >> > >> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that > >> tape library is hooked up to a different computer and was doing backups today. > > > > So, here is one thing that we can try to see whether these drives support > > long position information, even though they only claim to be SCSI-2. If > > they do, we can potentially add a quirk (or autodetection) to enable it. > > The code currently doesn't bother asking drives that claim to be SCSI-2 > > for long position information. (Because that feature was added in the > > SSC spec, which came after SCSI-2.) > > > > Issue a READ POSITION with the short form specified: > > > > camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > > > > Issue a READ POSITION with the vendor-specific block numbers: > > > > camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > > > > Issue a READ POSITION with the long form data: > > > > camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > > > > If it supports the last one, then I can put a quirk (or autodetection) in > > the driver and Bacula will get the hardware filemarks. You should try this > > on your SDLT as well. It may well support it. > > Sadly, no: > > [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000010 00 00 00 00 |....| > 00000014 > [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000010 00 00 00 00 |....| > 00000014 > [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > camcontrol: error sending command > (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00 > (pass2:ahc0:0:2:0): CAM status: SCSI Status Error > (pass2:ahc0:0:2:0): SCSI status: Check Condition > (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) > (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid > [root@cuppy:~] # Okay. Not too surprising I suppose. > The SDLT server is on 9.3 though: > > [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > cam_lookup_pass: No such file or directory > cam_lookup_pass: either the pass driver isn't in your kernel > cam_lookup_pass: or sa1 doesn't exist > [root@knew:/usr/home/dan] # uname -a > FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0: Tue Feb 24 21:28:03 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > [root@knew:/usr/home/dan] # > > > It took me a while to figure that out... there is no sa1 on *this* system. > > But, my SDLT: > > [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000010 00 00 00 00 |....| > 00000014 > [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000010 00 00 00 00 |....| > 00000014 > [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000020 > [root@knew:/usr/home/dan] # Just to confirm, can you send the output of: camcontrol inquiry sa0 -v I want to make certain it reports that it is SCSI-2. If so, I'll change the check in the driver to try asking for long position information on SCSI-2 devices. If it fails, it'll fall back to the regular method. > > > > Google didn't quickly produce a SCSI manual for the DEC drive, but the > > Quantum SDLT manual indicates that it supports long position data, despite > > identifying itself as a SCSI-2 drive. > > > >>> === Append files test === > >>>> > >>>> This test is essential to Bacula. > >>>> > >>>> I'm going to write one record in file 0, > >>>> two records in file 1, > >>>> and three records in file 2 > >>>> > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1420-0 Now moving to end of medium. > >>>> btape: btape.c:625-0 Moved to end of medium. > >>>> We should be in file 3. I am at file 3. This is correct! > >>>> > >>>> Now the important part, I am going to attempt to append to the tape. > >>>> > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> Done appending, there should be no I/O errors > >>>> > >>>> Doing Bacula scan of blocks: > >>>> 1 block of 64448 bytes in file 1 > >>>> End of File mark. > >>>> 2 blocks of 64448 bytes in file 2 > >>>> End of File mark. > >>>> 3 blocks of 64448 bytes in file 3 > >>>> End of File mark. > >>>> 1 block of 64448 bytes in file 4 > >>>> End of File mark. > >>>> Total files=4, blocks=7, bytes = 451,136 > >>>> End scanning the tape. > >>>> We should be in file 4. I am at file 4. This is correct! > >>>> > >>>> > >>>> It looks like the test worked this time, please add: > >>>> > >>>> Hardware End of Medium = No > >>>> > >>>> Fast Forward Space File = No > >>>> to your Device resource in the Storage conf file. > >>>> > >>>> The above Bacula scan should have output identical to what follows. > >>>> Please double check it ... > >>>> === Sample correct output === > >>>> 1 block of 64448 bytes in file 1 > >>>> End of File mark. > >>>> 2 blocks of 64448 bytes in file 2 > >>>> End of File mark. > >>>> 3 blocks of 64448 bytes in file 3 > >>>> End of File mark. > >>>> 1 block of 64448 bytes in file 4 > >>>> End of File mark. > >>>> Total files=4, blocks=7, bytes = 451,136 > >>>> === End sample correct output === > >>>> > >>>> If the above scan output is not identical to the > >>>> sample output, you MUST correct the problem > >>>> or Bacula will not be able to write multiple Jobs to > >>>> the tape. > >>>> > >>>> Skipping read backwards test because BSR turned off. > >>>> > >>>> > >>>> === Forward space files test === > >>>> > >>>> This test is essential to Bacula. > >>>> > >>>> I'm going to write five files then test forward spacing > >>>> > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>> btape: btape.c:1909-0 Wrote block to device. > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1634-0 Now forward spacing 1 file. > >>>> We should be in file 1. I am at file 1. This is correct! > >>>> btape: btape.c:1646-0 Now forward spacing 2 files. > >>>> We should be in file 3. I am at file 3. This is correct! > >>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1659-0 Now forward spacing 4 files. > >>>> We should be in file 4. I am at file 4. This is correct! > >>>> > >>>> btape: btape.c:1677-0 Now forward spacing 1 more file. > >>>> We should be in file 5. I am at file 5. This is correct! > >>>> > >>>> === End Forward space files test === > >>>> > >>>> > >>>> Ah, I see you have an autochanger configured. > >>>> To test the autochanger you must have a blank tape > >>>> that I can write on in Slot 1. > >>>> > >>>> Do you wish to continue with the Autochanger test? (y/n): y > >>>> > >>>> > >>>> === Autochanger test === > >>>> > >>>> 3301 Issuing autochanger "loaded" command. > >>>> Nothing loaded in the drive. OK. > >>>> 3303 Issuing autochanger "load 1 0" command. > >>>> 3303 Autochanger "load 1 0" status is OK. > >>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>> btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) > >>>> btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) > >>>> > >>>> The test autochanger worked!! > >>> > >>> Great, thanks for running the test! Looks like things are working as well > >>> as they were before. > >>> > >>>>> > >>>>>> 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.) > >>>> > >>>> Errors are interesting to me. Especially corrected errors. They are a good indicator of tape quality. > >>>> > >>> > >>> Yes. At least on modern drives, there is a good bit available in the log > >>> pages. You can try seeing what logs your drive supports by installing the > >>> sg3_utils package and running 'sg_logs sa1 --all'. > >>> > >>> Given the large amount of data available on some drives, and the difficulty > >>> distilling it down to a clear good/bad, I probably won't stick that in the > >>> 'mt status' output. > >>> > >>> But you can certainly take a look at it and have an idea of whether your > >>> particular tape/drive are experiencing issues. > >> > >> That's a lot of output: https://gist.github.com/dlangille/0e15a7fbf7acab56fd32 > > > > That is a lot. > > > >> I will run some Bacula jobs soon. I'm still setting up config files. > > > > Thanks for all the testing, I really appreciate it! > > > > Ken > > -- > > Kenneth Merry > > ken@FreeBSD.ORG > > ? > Dan Langille > http://langille.org/ > > > > > Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 16:43:18 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 66E46B28; Mon, 2 Mar 2015 16:43:18 +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 3A179FE4; Mon, 2 Mar 2015 16:43:17 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 903706D85 ; Mon, 2 Mar 2015 16:43:16 +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: <20150302020608.GA73433@mithlond.kdm.org> Date: Mon, 2 Mar 2015 11:43:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30C55F00-2DE4-4596-96EA-2E3CC40B4DB6@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> <20150302003658.GA72258@mithlond.kdm.org> <20150302020608.GA73433@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: Mon, 02 Mar 2015 16:43:18 -0000 > On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry wrote: >=20 > On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: >>=20 >>> On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: >>>>=20 >>>>> On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>> On Sun, Mar 01, 2015 at 17:06:24 -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 >>>>>>> =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 >>>>>>=20 >>>>>> # mtx -f /dev/pass0 status >>>>>> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) >>>>>> Data Transfer Element 0:Empty >>>>>> Data Transfer Element 1:Empty >>>>>> Storage Element 1:Empty >>>>>> Storage Element 2:Empty >>>>>> Storage Element 3:Empty >>>>>> Storage Element 4:Full :VolumeTag=3DFAI260 = =20 >>>>>> Storage Element 5:Full :VolumeTag=3DFAI261 = =20 >>>>>> Storage Element 6:Full :VolumeTag=3DFAI262 = =20 >>>>>> Storage Element 7:Full :VolumeTag=3DFAI263 = =20 >>>>>> Storage Element 8:Empty >>>>>> Storage Element 9:Empty >>>>>> Storage Element 10:Empty >>>>>>=20 >>>>>>=20 >>>>>> It was at this point I spent the next 90 minute trying to get the = tape=20 >>>>>> drive out of the tape library to free a stuck tape. Some of this = was spent >>>>>> attempting, and failing, to undo a stripped screw. I stopped the = attempt when >>>>>> I noticed the screw did need to be removed. :/ >>>>>=20 >>>>> Thanks for all of the effort! Looks like it is paying off! :) >>>>>=20 >>>>>> When I do this command, I hear the drive move a bit, to read the = tape: >>>>>>=20 >>>>>> # mt -f /dev/nsa1 status >>>>>> Drive: sa1: Serial Number: CXA09S1340 >>>>>> --------------------------------- >>>>>> Mode Density Blocksize bpi = Compression >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >>>>>> --------------------------------- >>>>>> Current Driver State: at rest. >>>>>> --------------------------------- >>>>>> Partition: 0 Calc File Number: 0 Calc Record Number: = 0 >>>>>> Residual: 0 Reported File Number: -1 Reported Record Number: = -1 >>>>>> Flags: None >>>>>=20 >>>>> Looks like the drive isn't reporting position information. It = will still >>>>> be useful to try it with Bacula, though. >>>>>=20 >>>>>> # mt -f /dev/nsa1 ostatus =20 >>>>>> Mode Density Blocksize bpi = Compression >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> ---------available modes--------- >>>>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> --------------------------------- >>>>>> Current Driver State: at rest. >>>>>> --------------------------------- >>>>>> File Number: 0 Record Number: 0 Residual Count 0 >>>>>>=20 >>>>>>=20 >>>>>> After doing a very small tar -c and tar -x, I have: >>>>>>=20 >>>>>> # mt -f /dev/nsa1 /dev/nsa1 ostatus >>>>>> Mode Density Blocksize bpi = Compression >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> ---------available modes--------- >>>>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC >>>>>> --------------------------------- >>>>>> Current Driver State: at rest. >>>>>> --------------------------------- >>>>>> File Number: 0 Record Number: 7 Residual Count 0 >>>>>=20 >>>>> Woohoo! It works. >>>>>=20 >>>>>> # mt -f /dev/nsa1 status -v >>>>>> Drive: sa1: Serial Number: CXA09S1340 >>>>>> --------------------------------- >>>>>> Mode Density Blocksize bpi = Compression >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled = (IDRC) >>>>>> --------------------------------- >>>>>> Current Driver State: at rest. >>>>>> --------------------------------- >>>>>> Partition: 0 Calc File Number: 0 Calc Record Number: = 7 >>>>>> Residual: 0 Reported File Number: -1 Reported Record Number: = -1 >>>>>> Flags: None >>>>>> --------------------------------- >>>>>> Tape I/O parameters: >>>>>> Maximum I/O size allowed by driver and controller (maxio): 65536 = bytes >>>>>> Maximum I/O size reported by controller (cpi_maxio): 0 bytes >>>>>> Maximum block size supported by tape drive and media (max_blk): = 16777214 bytes >>>>>> Minimum block size supported by tape drive and media (min_blk): 2 = bytes >>>>>> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >>>>>> Maximum possible I/O size (max_effective_iosize): 65536 bytes >>>>>>=20 >>>>>> I may not get to testing Bacula today. =20 >>>>>>=20 >>>>>> Based on the above, is there any commands you'd like me to try? >>>>>=20 >>>>> Aside from making sure things work okay with Bacula, that is = probably >>>>> sufficient. These drives won't support density reports or = position >>>>> information. >>>>>=20 >>>>>> Read below regarding two tape drives >>>>>>=20 >>>>>>>=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 >>>>>> How does this affect a tape library with more than one tape = drive? >>>>>>=20 >>>>>> [root@cuppy:~] # camcontrol amcontrol devlist >>>>>> at scbus0 target 0 lun 0 = (pass0,ch0) >>>>>> at scbus0 target 2 lun 0 = (sa1,pass2) >>>>>> at scbus1 target 0 lun 0 = (pass3,ada0) >>>>>> at scbus2 target 0 lun 0 = (pass4,ada1) >>>>>> at scbus3 target 0 lun 0 = (pass5,ses0) >>>>>>=20 >>>>>> This system has two tapes drives and I can access them through = the front panel but: >>>>>>=20 >>>>>> # ls -l /dev/*sa* >>>>>> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 >>>>>> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 >>>>>> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 >>>>>> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl >>>>>>=20 >>>>>> ... only one tape drives shows up. >>>>>=20 >>>>>=20 >>>>> Hmm. The tape drive is listed as sa1, which implies that there = may be an >>>>> sa0 that was there previously or is in the process of probing. = What does >>>>> dmesg show? How about 'camcontrol devlist -v'? >>>>=20 >>>> # camcontrol devlist -v >>>> scbus0 on ahc0 bus 0: >>>> at scbus0 target 0 lun 0 = (pass0,ch0) >>>> at scbus0 target 2 lun 0 = (sa1,pass2) >>>> <> at scbus0 target -1 lun ffffffff = () >>>> scbus1 on ahcich2 bus 0: >>>> at scbus1 target 0 lun 0 = (pass3,ada0) >>>> <> at scbus1 target -1 lun ffffffff = () >>>> scbus2 on ahcich4 bus 0: >>>> at scbus2 target 0 lun 0 = (pass4,ada1) >>>> <> at scbus2 target -1 lun ffffffff = () >>>> scbus3 on ahciem0 bus 0: >>>> at scbus3 target 0 lun 0 = (pass5,ses0) >>>> <> at scbus3 target -1 lun ffffffff = () >>>> scbus-1 on xpt0 bus 0: >>>> <> at scbus-1 target -1 lun = ffffffff (xpt0) >>>>=20 >>>>=20 >>>> BUT! >>>>=20 >>>> # grep sa /var/run/dmesg.boot=20 >>>> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID >>>> module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error = 19 >>>> alc0: Using 1 MSIX message(s). >>>> isab0: at device 31.0 on pci0 >>>> isa0: on isab0 >>>> orm0: at iomem 0xce800-0xcefff on isa0 >>>> atkbdc0: at port 0x60,0x64 on isa0 >>>> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 >>>> sa0: Removable Sequential Access SCSI-2 = device=20 >>>> sa0: Serial Number CXA22S2338 >>>> sa0: 10.000MB/s transfers (10.000MHz, offset 15) >>>> sa0: quirks=3D0x100 >>>> sa1 at ahc0 bus 0 scbus0 target 2 lun 0 >>>> sa1: Removable Sequential Access SCSI-2 = device=20 >>>> sa1: Serial Number CXA09S1340 >>>> sa1: 10.000MB/s transfers (10.000MHz, offset 15) >>>> sa1: quirks=3D0x100 >>>=20 >>> If you run 'dmesg', you should have seen a message when it went = away. Perhaps >>> there will be something preceding it that will give us a clue about = the >>> problem. (Generally a selection timeout.) At least this does show = that >>> sa0 is at target 1, and so should not conflict with the library or = sa1. >>=20 >> Ahh: >>=20 >> Trying to mount root from zfs:system/bootenv/FreeBSDHEad []... >> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 >> sa0: s/n CXA22S2338 detached >> (sa0:ahc0:0:1:0): Periph destroyed >> arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on = em0 >> arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on = em0 >> arp: 10.55.0.60 moved from 78:ca:39:fe:d6:b3 to e4:ce:8f:46:f1:98 on = em0 >> (sa1:ahc0:0:2:0): 64512-byte tape record bigger than supplied buffer >> (sa1:ahc0:0:2:0): 10240-byte tape record bigger than supplied buffer >=20 > Okay. Well, no indication of what happened. Perhaps boot -v will = show it, > perhaps not. >=20 Good news. After a reboot, both tape drives are present: $ ls -l /dev/*sa* crw-rw---- 1 root operator 0x61 Mar 2 17:27 /dev/esa0 crw-rw---- 1 root operator 0x65 Mar 2 17:27 /dev/esa1 crw-rw---- 1 root operator 0x60 Mar 2 17:27 /dev/nsa0 crw-rw---- 1 root operator 0x64 Mar 2 17:27 /dev/nsa1 crw-rw---- 1 root operator 0x5f Mar 2 17:27 /dev/sa0 crw-rw---- 1 root operator 0x5e Mar 2 17:27 /dev/sa0.ctl crw-rw---- 1 root operator 0x63 Mar 2 17:27 /dev/sa1 crw-rw---- 1 root operator 0x62 Mar 2 17:27 /dev/sa1.ctl =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 16:44:11 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 94AD2C66; Mon, 2 Mar 2015 16:44:11 +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 5286CFF8; Mon, 2 Mar 2015 16:44:10 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id D16C86D87 ; Mon, 2 Mar 2015 16:44:09 +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: <20150302163146.GA85515@mithlond.kdm.org> Date: Mon, 2 Mar 2015 11:44:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@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: Mon, 02 Mar 2015 16:44:11 -0000 > On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry wrote: >=20 > On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: >>=20 >>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>>>=20 >>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>>>=20 >>>>>> Device { >>>>>> Name =3D DLT >>>>>> Description =3D "QUANTUM DLT7000 1624" >>>>>> Media Type =3D DLT >>>>>> Archive Device =3D /dev/nsa1 >>>>>>=20 >>>>>> Autochanger =3D YES >>>>>> Drive Index =3D 0 >>>>>>=20 >>>>>> Offline On Unmount =3D no >>>>>> Hardware End of Medium =3D yes >>>>>> BSF at EOM =3D yes >>>>>> Backward Space Record =3D no >>>>>> Fast Forward Space File =3D no >>>>>> TWO EOF =3D yes >>>>>> } >>>>>>=20 >>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) = has a btape test on this same model. >>>>>>=20 >>>>>> Here's the test I ran tonight: >>>>>>=20 >>>>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>>>> Tape block granularity is 1024 bytes. >>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>> *test >>>>>>=20 >>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>>>=20 >>>>>> I'm going to write 10000 records and an EOF >>>>>> then write 10000 records and an EOF, then rewind, >>>>>> and re-read the data to verify that it is correct. >>>>>>=20 >>>>>> This is an *essential* feature ... >>>>>>=20 >>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1210-0 Rewind OK. >>>>>> 10000 blocks re-read correctly. >>>>>> Got EOF on tape. >>>>>> 10000 blocks re-read correctly. >>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D= =3D >>>>>>=20 >>>>>> btape: btape.c:1277-0 Block position test >>>>>> btape: btape.c:1289-0 Rewind OK. >>>>>> Reposition to file:block 0:4 >>>>>> Block 5 re-read correctly. >>>>>> Reposition to file:block 0:200 >>>>>> Block 201 re-read correctly. >>>>>> Reposition to file:block 0:9999 >>>>>> Block 10000 re-read correctly. >>>>>> Reposition to file:block 1:0 >>>>>> Block 10001 re-read correctly. >>>>>> Reposition to file:block 1:600 >>>>>> Block 10601 re-read correctly. >>>>>> Reposition to file:block 1:9999 >>>>>> Block 20000 re-read correctly. >>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test =3D=3D= =3D >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>=20 >>>>>> This test is essential to Bacula. >>>>>>=20 >>>>>> I'm going to write one record in file 0, >>>>>> two records in file 1, >>>>>> and three records in file 2 >>>>>>=20 >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>=20 >>>>> This is the critical piece. The test moves the tape to the end of = the >>>>> medium. With hardware position information, you can tell what = filemark >>>>> you're on. Without it, you can't. >>>>>=20 >>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" = (/dev/nsa1). ERR=3DNo error: 0. >>>>>> We should be in file 3. I am at file 0. This is NOT correct!!!! >>>>>>=20 >>>>>> Append test failed. Attempting again. >>>>>> Setting "Hardware End of Medium =3D no >>>>>> and "Fast Forward Space File =3D no >>>>>> and retrying append test. >>>>>=20 >>>>> This is not surprsing, given that the drive doesn't support long = read >>>>> position data. (It's a SCSI-2 device.) So that means that Bacula = will >>>>> need to do it manually. >>>>=20 >>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but = that >>>> tape library is hooked up to a different computer and was doing = backups today. >>>=20 >>> So, here is one thing that we can try to see whether these drives = support >>> long position information, even though they only claim to be SCSI-2. = If >>> they do, we can potentially add a quirk (or autodetection) to enable = it. >>> The code currently doesn't bother asking drives that claim to be = SCSI-2 >>> for long position information. (Because that feature was added in = the >>> SSC spec, which came after SCSI-2.) >>>=20 >>> Issue a READ POSITION with the short form specified: >>>=20 >>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >>>=20 >>> Issue a READ POSITION with the vendor-specific block numbers: >>>=20 >>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >>>=20 >>> Issue a READ POSITION with the long form data: >>>=20 >>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >>>=20 >>> If it supports the last one, then I can put a quirk (or = autodetection) in >>> the driver and Bacula will get the hardware filemarks. You should = try this >>> on your SDLT as well. It may well support it. >>=20 >> Sadly, no: >>=20 >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i = 20 - |hd >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000010 00 00 00 00 |....| >> 00000014 >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i = 20 - |hd >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000010 00 00 00 00 |....| >> 00000014 >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i = 32 - |hd >> camcontrol: error sending command >> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00=20= >> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error >> (pass2:ahc0:0:2:0): SCSI status: Check Condition >> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid = field in CDB) >> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid >> [root@cuppy:~] #=20 >=20 > Okay. Not too surprising I suppose. >=20 >> The SDLT server is on 9.3 though: >>=20 >> [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 = 0 0 0" -i 20 - |hd >> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >> cam_lookup_pass: No such file or directory >> cam_lookup_pass: either the pass driver isn't in your kernel >> cam_lookup_pass: or sa1 doesn't exist >> [root@knew:/usr/home/dan] # uname -a >> FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 = #0: Tue Feb 24 21:28:03 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >> [root@knew:/usr/home/dan] #=20 >>=20 >>=20 >> It took me a while to figure that out... there is no sa1 on *this* = system. >>=20 >> But, my SDLT: >>=20 >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 = 0 0 0" -i 20 - |hd >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000010 00 00 00 00 |....| >> 00000014 >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 = 0 0 0" -i 20 - |hd >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000010 00 00 00 00 |....| >> 00000014 >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 = 0 0 0" -i 32 - |hd >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >> 00000020 >> [root@knew:/usr/home/dan] #=20 >=20 > Just to confirm, can you send the output of: >=20 > camcontrol inquiry sa0 -v >=20 > I want to make certain it reports that it is SCSI-2. If so, I'll = change > the check in the driver to try asking for long position information on > SCSI-2 devices. If it fails, it'll fall back to the regular method. [dan@knew:~] $ sudo camcontrol inquiry sa0 -v pass10: Removable Sequential Access SCSI-2 = device=20 pass10: Serial Number CXB46H0716 =20 pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) [dan@knew:~] $=20 >=20 >>>=20 >>> Google didn't quickly produce a SCSI manual for the DEC drive, but = the >>> Quantum SDLT manual indicates that it supports long position data, = despite >>> identifying itself as a SCSI-2 drive. >>>=20 >>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>=20 >>>>>> This test is essential to Bacula. >>>>>>=20 >>>>>> I'm going to write one record in file 0, >>>>>> two records in file 1, >>>>>> and three records in file 2 >>>>>>=20 >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>> btape: btape.c:625-0 Moved to end of medium. >>>>>> We should be in file 3. I am at file 3. This is correct! >>>>>>=20 >>>>>> Now the important part, I am going to attempt to append to the = tape. >>>>>>=20 >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> Done appending, there should be no I/O errors >>>>>>=20 >>>>>> Doing Bacula scan of blocks: >>>>>> 1 block of 64448 bytes in file 1 >>>>>> End of File mark. >>>>>> 2 blocks of 64448 bytes in file 2 >>>>>> End of File mark. >>>>>> 3 blocks of 64448 bytes in file 3 >>>>>> End of File mark. >>>>>> 1 block of 64448 bytes in file 4 >>>>>> End of File mark. >>>>>> Total files=3D4, blocks=3D7, bytes =3D 451,136 >>>>>> End scanning the tape. >>>>>> We should be in file 4. I am at file 4. This is correct! >>>>>>=20 >>>>>>=20 >>>>>> It looks like the test worked this time, please add: >>>>>>=20 >>>>>> Hardware End of Medium =3D No >>>>>>=20 >>>>>> Fast Forward Space File =3D No >>>>>> to your Device resource in the Storage conf file. >>>>>>=20 >>>>>> The above Bacula scan should have output identical to what = follows. >>>>>> Please double check it ... >>>>>> =3D=3D=3D Sample correct output =3D=3D=3D >>>>>> 1 block of 64448 bytes in file 1 >>>>>> End of File mark. >>>>>> 2 blocks of 64448 bytes in file 2 >>>>>> End of File mark. >>>>>> 3 blocks of 64448 bytes in file 3 >>>>>> End of File mark. >>>>>> 1 block of 64448 bytes in file 4 >>>>>> End of File mark. >>>>>> Total files=3D4, blocks=3D7, bytes =3D 451,136 >>>>>> =3D=3D=3D End sample correct output =3D=3D=3D >>>>>>=20 >>>>>> If the above scan output is not identical to the >>>>>> sample output, you MUST correct the problem >>>>>> or Bacula will not be able to write multiple Jobs to=20 >>>>>> the tape. >>>>>>=20 >>>>>> Skipping read backwards test because BSR turned off. >>>>>>=20 >>>>>>=20 >>>>>> =3D=3D=3D Forward space files test =3D=3D=3D >>>>>>=20 >>>>>> This test is essential to Bacula. >>>>>>=20 >>>>>> I'm going to write five files then test forward spacing >>>>>>=20 >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1634-0 Now forward spacing 1 file. >>>>>> We should be in file 1. I am at file 1. This is correct! >>>>>> btape: btape.c:1646-0 Now forward spacing 2 files. >>>>>> We should be in file 3. I am at file 3. This is correct! >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1659-0 Now forward spacing 4 files. >>>>>> We should be in file 4. I am at file 4. This is correct! >>>>>>=20 >>>>>> btape: btape.c:1677-0 Now forward spacing 1 more file. >>>>>> We should be in file 5. I am at file 5. This is correct! >>>>>>=20 >>>>>> =3D=3D=3D End Forward space files test =3D=3D=3D >>>>>>=20 >>>>>>=20 >>>>>> Ah, I see you have an autochanger configured. >>>>>> To test the autochanger you must have a blank tape >>>>>> that I can write on in Slot 1. >>>>>>=20 >>>>>> Do you wish to continue with the Autochanger test? (y/n): y >>>>>>=20 >>>>>>=20 >>>>>> =3D=3D=3D Autochanger test =3D=3D=3D >>>>>>=20 >>>>>> 3301 Issuing autochanger "loaded" command. >>>>>> Nothing loaded in the drive. OK. >>>>>> 3303 Issuing autochanger "load 1 0" command. >>>>>> 3303 Autochanger "load 1 0" status is OK. >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>> btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1) >>>>>> btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1) >>>>>>=20 >>>>>> The test autochanger worked!! >>>>>=20 >>>>> Great, thanks for running the test! Looks like things are working = as well >>>>> as they were before. >>>>>=20 >>>>>>>=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 >>>>>> Errors are interesting to me. Especially corrected errors. They = are a good indicator of tape quality. >>>>>>=20 >>>>>=20 >>>>> Yes. At least on modern drives, there is a good bit available in = the log >>>>> pages. You can try seeing what logs your drive supports by = installing the >>>>> sg3_utils package and running 'sg_logs sa1 --all'. >>>>>=20 >>>>> Given the large amount of data available on some drives, and the = difficulty >>>>> distilling it down to a clear good/bad, I probably won't stick = that in the >>>>> 'mt status' output. >>>>>=20 >>>>> But you can certainly take a look at it and have an idea of = whether your >>>>> particular tape/drive are experiencing issues. >>>>=20 >>>> That's a lot of output: = https://gist.github.com/dlangille/0e15a7fbf7acab56fd32 >>>=20 >>> That is a lot. >>>=20 >>>> I will run some Bacula jobs soon. I'm still setting up config = files. >>>=20 >>> Thanks for all the testing, I really appreciate it! >>>=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 Mon Mar 2 16:46:01 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 3C08DED7; Mon, 2 Mar 2015 16:46:01 +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 145A2A1; Mon, 2 Mar 2015 16:46:00 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id D72D56D88 ; Mon, 2 Mar 2015 16:45:59 +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: <20150214003232.GA63990@mithlond.kdm.org> Date: Mon, 2 Mar 2015 11:45:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8EFB1A84-96E6-4F63-A6D0-A87432C02B72@langille.org> References: <20150214003232.GA63990@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: Mon, 02 Mar 2015 16:46:01 -0000 > 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. This came to me today via the Bacula mailing lists. http://marc.info/?l=3Dbacula-users&m=3D142531236722693&w=3D2 > As far as I can tell ltfs support on linux sits on top of the standard = mt-st stuff \ > as a userspace (fuse) filesystem=20 > I'd hope it's much the same with BSD. Removing the standard interface = would be \ > counterproductive overall Can you answer that and I'll relay please? =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 17:26:33 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 350131C4; Mon, 2 Mar 2015 17:26:33 +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 D2A9878D; Mon, 2 Mar 2015 17:26:32 +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 t22HQTcu087076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 10:26:29 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22HQT7p087075; Mon, 2 Mar 2015 10:26:29 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 10:26:29 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302172629.GA87055@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> <20150302003658.GA72258@mithlond.kdm.org> <20150302020608.GA73433@mithlond.kdm.org> <30C55F00-2DE4-4596-96EA-2E3CC40B4DB6@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30C55F00-2DE4-4596-96EA-2E3CC40B4DB6@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]); Mon, 02 Mar 2015 10:26:29 -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: Mon, 02 Mar 2015 17:26:33 -0000 On Mon, Mar 02, 2015 at 11:43:15 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry wrote: > > > > On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: > >> > >>> On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry wrote: > >>> > >>> On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: > >>>> > >>>>> On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry wrote: > >>>>> > >>>>> On Sun, Mar 01, 2015 at 17:06:24 -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. > >>>>>>> > >>>>>>> ============ > >>>>>>> Rough draft commit message: > >>>>>>> > >>>>>>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt > >>>>>>> > >>>>>>> The patches against FreeBSD/head as of SVN revision 278706: > >>>>>>> > >>>>>>> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt > >>>>>>> > >>>>>>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278721. > >>>>>>> > >>>>>>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt > >>>>>>> ============ > >>>>>>> > >>>>>>> The intent is to get the tape infrastructure more up to date, so we can > >>>>>>> support LTFS and more modern tape drives: > >>>>>>> > >>>>>>> http://www.ibm.com/systems/storage/tape/ltfs/ > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> The commit message below outlines most of the changes. > >>>>>>> > >>>>>>> A few comments: > >>>>>>> > >>>>>>> 1. I'm planning to commit the XPT_DEV_ADVINFO changes separately. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> 3. I have tested with a reasonable amount of tape hardware (see below for a > >>>>>>> list), but more testing and feedback would be good. > >>>>>>> > >>>>>>> 4. Standard 'mt status' output looks like this: > >>>>>>> > >>>>>>> # 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 > >>>>>>> > >>>>>>> 5. 'mt status -v' looks like this: > >>>>>>> > >>>>>>> # 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 > >>>>>> > >>>>>> > >>>>>> # mtx -f /dev/pass0 status > >>>>>> Storage Changer /dev/pass0:2 Drives, 10 Slots ( 0 Import/Export ) > >>>>>> Data Transfer Element 0:Empty > >>>>>> Data Transfer Element 1:Empty > >>>>>> Storage Element 1:Empty > >>>>>> Storage Element 2:Empty > >>>>>> Storage Element 3:Empty > >>>>>> Storage Element 4:Full :VolumeTag=FAI260 > >>>>>> Storage Element 5:Full :VolumeTag=FAI261 > >>>>>> Storage Element 6:Full :VolumeTag=FAI262 > >>>>>> Storage Element 7:Full :VolumeTag=FAI263 > >>>>>> Storage Element 8:Empty > >>>>>> Storage Element 9:Empty > >>>>>> Storage Element 10:Empty > >>>>>> > >>>>>> > >>>>>> It was at this point I spent the next 90 minute trying to get the tape > >>>>>> drive out of the tape library to free a stuck tape. Some of this was spent > >>>>>> attempting, and failing, to undo a stripped screw. I stopped the attempt when > >>>>>> I noticed the screw did need to be removed. :/ > >>>>> > >>>>> Thanks for all of the effort! Looks like it is paying off! :) > >>>>> > >>>>>> When I do this command, I hear the drive move a bit, to read the tape: > >>>>>> > >>>>>> # mt -f /dev/nsa1 status > >>>>>> Drive: sa1: Serial Number: CXA09S1340 > >>>>>> --------------------------------- > >>>>>> Mode Density Blocksize bpi Compression > >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >>>>>> --------------------------------- > >>>>>> Current Driver State: at rest. > >>>>>> --------------------------------- > >>>>>> Partition: 0 Calc File Number: 0 Calc Record Number: 0 > >>>>>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >>>>>> Flags: None > >>>>> > >>>>> Looks like the drive isn't reporting position information. It will still > >>>>> be useful to try it with Bacula, though. > >>>>> > >>>>>> # mt -f /dev/nsa1 ostatus > >>>>>> Mode Density Blocksize bpi Compression > >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> ---------available modes--------- > >>>>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> --------------------------------- > >>>>>> Current Driver State: at rest. > >>>>>> --------------------------------- > >>>>>> File Number: 0 Record Number: 0 Residual Count 0 > >>>>>> > >>>>>> > >>>>>> After doing a very small tar -c and tar -x, I have: > >>>>>> > >>>>>> # mt -f /dev/nsa1 /dev/nsa1 ostatus > >>>>>> Mode Density Blocksize bpi Compression > >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> ---------available modes--------- > >>>>>> 0: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 1: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 2: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> 3: 0x1b:DLTapeIV(35GB) variable 85937 IDRC > >>>>>> --------------------------------- > >>>>>> Current Driver State: at rest. > >>>>>> --------------------------------- > >>>>>> File Number: 0 Record Number: 7 Residual Count 0 > >>>>> > >>>>> Woohoo! It works. > >>>>> > >>>>>> # mt -f /dev/nsa1 status -v > >>>>>> Drive: sa1: Serial Number: CXA09S1340 > >>>>>> --------------------------------- > >>>>>> Mode Density Blocksize bpi Compression > >>>>>> Current: 0x1b:DLTapeIV(35GB) variable 85937 enabled (IDRC) > >>>>>> --------------------------------- > >>>>>> Current Driver State: at rest. > >>>>>> --------------------------------- > >>>>>> Partition: 0 Calc File Number: 0 Calc Record Number: 7 > >>>>>> Residual: 0 Reported File Number: -1 Reported Record Number: -1 > >>>>>> Flags: None > >>>>>> --------------------------------- > >>>>>> Tape I/O parameters: > >>>>>> Maximum I/O size allowed by driver and controller (maxio): 65536 bytes > >>>>>> Maximum I/O size reported by controller (cpi_maxio): 0 bytes > >>>>>> Maximum block size supported by tape drive and media (max_blk): 16777214 bytes > >>>>>> Minimum block size supported by tape drive and media (min_blk): 2 bytes > >>>>>> Block granularity supported by tape drive and media (blk_gran): 0 bytes > >>>>>> Maximum possible I/O size (max_effective_iosize): 65536 bytes > >>>>>> > >>>>>> I may not get to testing Bacula today. > >>>>>> > >>>>>> Based on the above, is there any commands you'd like me to try? > >>>>> > >>>>> Aside from making sure things work okay with Bacula, that is probably > >>>>> sufficient. These drives won't support density reports or position > >>>>> information. > >>>>> > >>>>>> Read below regarding two tape drives > >>>>>> > >>>>>>> > >>>>>>> 6. Existing applications should work without changes. If not, please let > >>>>>>> me know. Hopefully they will move over time to the new interfaces. > >>>>>>> > >>>>>>> 7. There are lots of additional features that could be added later. > >>>>>>> Append-only support, encryption, more log pages, etc. > >>>>>>> > >>>>>>> 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 > >>>>>>> to the status XML from the sa(4) driver. > >>>>>>> > >>>>>>> ============ > >>>>>>> Significant upgrades to sa(4) and mt(1). > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> Significant changes and new features include: > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been removed. > >>>>>> > >>>>>> How does this affect a tape library with more than one tape drive? > >>>>>> > >>>>>> [root@cuppy:~] # camcontrol amcontrol devlist > >>>>>> at scbus0 target 0 lun 0 (pass0,ch0) > >>>>>> at scbus0 target 2 lun 0 (sa1,pass2) > >>>>>> at scbus1 target 0 lun 0 (pass3,ada0) > >>>>>> at scbus2 target 0 lun 0 (pass4,ada1) > >>>>>> at scbus3 target 0 lun 0 (pass5,ses0) > >>>>>> > >>>>>> This system has two tapes drives and I can access them through the front panel but: > >>>>>> > >>>>>> # ls -l /dev/*sa* > >>>>>> crw-rw---- 1 root operator 0x65 Feb 28 22:04 /dev/esa1 > >>>>>> crw-rw---- 1 root operator 0x64 Mar 1 22:43 /dev/nsa1 > >>>>>> crw-rw---- 1 root operator 0x63 Feb 28 22:04 /dev/sa1 > >>>>>> crw-rw---- 1 root operator 0x62 Feb 28 22:04 /dev/sa1.ctl > >>>>>> > >>>>>> ... only one tape drives shows up. > >>>>> > >>>>> > >>>>> Hmm. The tape drive is listed as sa1, which implies that there may be an > >>>>> sa0 that was there previously or is in the process of probing. What does > >>>>> dmesg show? How about 'camcontrol devlist -v'? > >>>> > >>>> # camcontrol devlist -v > >>>> scbus0 on ahc0 bus 0: > >>>> at scbus0 target 0 lun 0 (pass0,ch0) > >>>> at scbus0 target 2 lun 0 (sa1,pass2) > >>>> <> at scbus0 target -1 lun ffffffff () > >>>> scbus1 on ahcich2 bus 0: > >>>> at scbus1 target 0 lun 0 (pass3,ada0) > >>>> <> at scbus1 target -1 lun ffffffff () > >>>> scbus2 on ahcich4 bus 0: > >>>> at scbus2 target 0 lun 0 (pass4,ada1) > >>>> <> at scbus2 target -1 lun ffffffff () > >>>> scbus3 on ahciem0 bus 0: > >>>> at scbus3 target 0 lun 0 (pass5,ses0) > >>>> <> at scbus3 target -1 lun ffffffff () > >>>> scbus-1 on xpt0 bus 0: > >>>> <> at scbus-1 target -1 lun ffffffff (xpt0) > >>>> > >>>> > >>>> BUT! > >>>> > >>>> # grep sa /var/run/dmesg.boot > >>>> VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID > >>>> module_register_init: MOD_LOAD (vesa, 0xffffffff80de3720, 0) error 19 > >>>> alc0: Using 1 MSIX message(s). > >>>> isab0: at device 31.0 on pci0 > >>>> isa0: on isab0 > >>>> orm0: at iomem 0xce800-0xcefff on isa0 > >>>> atkbdc0: at port 0x60,0x64 on isa0 > >>>> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > >>>> sa0: Removable Sequential Access SCSI-2 device > >>>> sa0: Serial Number CXA22S2338 > >>>> sa0: 10.000MB/s transfers (10.000MHz, offset 15) > >>>> sa0: quirks=0x100 > >>>> sa1 at ahc0 bus 0 scbus0 target 2 lun 0 > >>>> sa1: Removable Sequential Access SCSI-2 device > >>>> sa1: Serial Number CXA09S1340 > >>>> sa1: 10.000MB/s transfers (10.000MHz, offset 15) > >>>> sa1: quirks=0x100 > >>> > >>> If you run 'dmesg', you should have seen a message when it went away. Perhaps > >>> there will be something preceding it that will give us a clue about the > >>> problem. (Generally a selection timeout.) At least this does show that > >>> sa0 is at target 1, and so should not conflict with the library or sa1. > >> > >> Ahh: > >> > >> Trying to mount root from zfs:system/bootenv/FreeBSDHEad []... > >> sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > >> sa0: s/n CXA22S2338 detached > >> (sa0:ahc0:0:1:0): Periph destroyed > >> arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 > >> arp: 10.55.0.60 moved from e4:ce:8f:46:f1:98 to 78:ca:39:fe:d6:b3 on em0 > >> arp: 10.55.0.60 moved from 78:ca:39:fe:d6:b3 to e4:ce:8f:46:f1:98 on em0 > >> (sa1:ahc0:0:2:0): 64512-byte tape record bigger than supplied buffer > >> (sa1:ahc0:0:2:0): 10240-byte tape record bigger than supplied buffer > > > > Okay. Well, no indication of what happened. Perhaps boot -v will show it, > > perhaps not. > > > > Good news. After a reboot, both tape drives are present: > > $ ls -l /dev/*sa* > crw-rw---- 1 root operator 0x61 Mar 2 17:27 /dev/esa0 > crw-rw---- 1 root operator 0x65 Mar 2 17:27 /dev/esa1 > crw-rw---- 1 root operator 0x60 Mar 2 17:27 /dev/nsa0 > crw-rw---- 1 root operator 0x64 Mar 2 17:27 /dev/nsa1 > crw-rw---- 1 root operator 0x5f Mar 2 17:27 /dev/sa0 > crw-rw---- 1 root operator 0x5e Mar 2 17:27 /dev/sa0.ctl > crw-rw---- 1 root operator 0x63 Mar 2 17:27 /dev/sa1 > crw-rw---- 1 root operator 0x62 Mar 2 17:27 /dev/sa1.ctl > Ahh, good. Glad it is working now! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 17:28:50 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 2D731322; Mon, 2 Mar 2015 17:28:50 +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 C90017B7; Mon, 2 Mar 2015 17:28:49 +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 t22HSlGp087099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 10:28:47 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22HSksW087098; Mon, 2 Mar 2015 10:28:46 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 10:28:46 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302172846.GB87055@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85E2DDA0-4A2B-4316-A318-3706B3A05C11@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]); Mon, 02 Mar 2015 10:28:47 -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: Mon, 02 Mar 2015 17:28:50 -0000 On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: > > > On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry wrote: > > > > On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: > >> > >>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry wrote: > >>> > >>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: > >>>> > >>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry wrote: > >>>>> > >>>>> On Sun, Mar 01, 2015 at 19:15:05 -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. > >>>>>>> > >>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf > >>>>>> > >>>>>> Device { > >>>>>> Name = DLT > >>>>>> Description = "QUANTUM DLT7000 1624" > >>>>>> Media Type = DLT > >>>>>> Archive Device = /dev/nsa1 > >>>>>> > >>>>>> Autochanger = YES > >>>>>> Drive Index = 0 > >>>>>> > >>>>>> Offline On Unmount = no > >>>>>> Hardware End of Medium = yes > >>>>>> BSF at EOM = yes > >>>>>> Backward Space Record = no > >>>>>> Fast Forward Space File = no > >>>>>> TWO EOF = yes > >>>>>> } > >>>>>> > >>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model. > >>>>>> > >>>>>> Here's the test I ran tonight: > >>>>>> > >>>>>> [root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 > >>>>>> Tape block granularity is 1024 bytes. > >>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. > >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>>>> *test > >>>>>> > >>>>>> === Write, rewind, and re-read test === > >>>>>> > >>>>>> I'm going to write 10000 records and an EOF > >>>>>> then write 10000 records and an EOF, then rewind, > >>>>>> and re-read the data to verify that it is correct. > >>>>>> > >>>>>> This is an *essential* feature ... > >>>>>> > >>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1210-0 Rewind OK. > >>>>>> 10000 blocks re-read correctly. > >>>>>> Got EOF on tape. > >>>>>> 10000 blocks re-read correctly. > >>>>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>>>> > >>>>>> btape: btape.c:1277-0 Block position test > >>>>>> btape: btape.c:1289-0 Rewind OK. > >>>>>> Reposition to file:block 0:4 > >>>>>> Block 5 re-read correctly. > >>>>>> Reposition to file:block 0:200 > >>>>>> Block 201 re-read correctly. > >>>>>> Reposition to file:block 0:9999 > >>>>>> Block 10000 re-read correctly. > >>>>>> Reposition to file:block 1:0 > >>>>>> Block 10001 re-read correctly. > >>>>>> Reposition to file:block 1:600 > >>>>>> Block 10601 re-read correctly. > >>>>>> Reposition to file:block 1:9999 > >>>>>> Block 20000 re-read correctly. > >>>>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>>>> > >>>>>> > >>>>>> > >>>>>> === Append files test === > >>>>>> > >>>>>> This test is essential to Bacula. > >>>>>> > >>>>>> I'm going to write one record in file 0, > >>>>>> two records in file 1, > >>>>>> and three records in file 2 > >>>>>> > >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>>>> btape: btape.c:1420-0 Now moving to end of medium. > >>>>> > >>>>> This is the critical piece. The test moves the tape to the end of the > >>>>> medium. With hardware position information, you can tell what filemark > >>>>> you're on. Without it, you can't. > >>>>> > >>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0. > >>>>>> We should be in file 3. I am at file 0. This is NOT correct!!!! > >>>>>> > >>>>>> Append test failed. Attempting again. > >>>>>> Setting "Hardware End of Medium = no > >>>>>> and "Fast Forward Space File = no > >>>>>> and retrying append test. > >>>>> > >>>>> This is not surprsing, given that the drive doesn't support long read > >>>>> position data. (It's a SCSI-2 device.) So that means that Bacula will > >>>>> need to do it manually. > >>>> > >>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that > >>>> tape library is hooked up to a different computer and was doing backups today. > >>> > >>> So, here is one thing that we can try to see whether these drives support > >>> long position information, even though they only claim to be SCSI-2. If > >>> they do, we can potentially add a quirk (or autodetection) to enable it. > >>> The code currently doesn't bother asking drives that claim to be SCSI-2 > >>> for long position information. (Because that feature was added in the > >>> SSC spec, which came after SCSI-2.) > >>> > >>> Issue a READ POSITION with the short form specified: > >>> > >>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >>> > >>> Issue a READ POSITION with the vendor-specific block numbers: > >>> > >>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > >>> > >>> Issue a READ POSITION with the long form data: > >>> > >>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > >>> > >>> If it supports the last one, then I can put a quirk (or autodetection) in > >>> the driver and Bacula will get the hardware filemarks. You should try this > >>> on your SDLT as well. It may well support it. > >> > >> Sadly, no: > >> > >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000010 00 00 00 00 |....| > >> 00000014 > >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000010 00 00 00 00 |....| > >> 00000014 > >> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > >> camcontrol: error sending command > >> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00 > >> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error > >> (pass2:ahc0:0:2:0): SCSI status: Check Condition > >> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) > >> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid > >> [root@cuppy:~] # > > > > Okay. Not too surprising I suppose. > > > >> The SDLT server is on 9.3 though: > >> > >> [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > >> cam_lookup_pass: No such file or directory > >> cam_lookup_pass: either the pass driver isn't in your kernel > >> cam_lookup_pass: or sa1 doesn't exist > >> [root@knew:/usr/home/dan] # uname -a > >> FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0: Tue Feb 24 21:28:03 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > >> [root@knew:/usr/home/dan] # > >> > >> > >> It took me a while to figure that out... there is no sa1 on *this* system. > >> > >> But, my SDLT: > >> > >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000010 00 00 00 00 |....| > >> 00000014 > >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000010 00 00 00 00 |....| > >> 00000014 > >> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > >> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >> 00000020 > >> [root@knew:/usr/home/dan] # > > > > Just to confirm, can you send the output of: > > > > camcontrol inquiry sa0 -v > > > > I want to make certain it reports that it is SCSI-2. If so, I'll change > > the check in the driver to try asking for long position information on > > SCSI-2 devices. If it fails, it'll fall back to the regular method. > > [dan@knew:~] $ sudo camcontrol inquiry sa0 -v > pass10: Removable Sequential Access SCSI-2 device > pass10: Serial Number CXB46H0716 > pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) > [dan@knew:~] $ Okay. Doing the check doesn't cause any problems on my collection of old tape drives, so I'll go ahead and enable checking on SCSI-2 devices. The primary thing is just making sure it doesn't cause tape drive to choke if we request long position information. It doesn't appear to be an issue. If we do run into one, we can put in a quirk. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 17:39:17 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 80281877; Mon, 2 Mar 2015 17:39:17 +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 24E7C908; Mon, 2 Mar 2015 17:39:17 +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 t22HdFki087288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 10:39:15 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22HdFQc087287; Mon, 2 Mar 2015 10:39:15 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 10:39:15 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302173914.GC87055@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <8EFB1A84-96E6-4F63-A6D0-A87432C02B72@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EFB1A84-96E6-4F63-A6D0-A87432C02B72@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]); Mon, 02 Mar 2015 10:39:15 -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: Mon, 02 Mar 2015 17:39:17 -0000 On Mon, Mar 02, 2015 at 11:45:59 -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. > > This came to me today via the Bacula mailing lists. > > http://marc.info/?l=bacula-users&m=142531236722693&w=2 > > > As far as I can tell ltfs support on linux sits on top of the standard mt-st stuff \ > > as a userspace (fuse) filesystem > > I'd hope it's much the same with BSD. Removing the standard interface would be \ > > counterproductive overall > > Can you answer that and I'll relay please? Sure. In short, the current interface will stay in place. I have added additional ioctls that provide more features and information, but I don't see any issue with leaving the current ioctls in place. The MTIOCGET ioctl even gets an improvement in behavior when the tape drive supports long position information -- it will report the file number after a 'mt eod'. IBM's LTFS sits on top of their own Linux tape driver, and operates with a combination of tape driver ioctls (e.g. the standard MTIOTCOP ioctls) and SCSI passthrough. When I ported it to FreeBSD, I ran into several areas where we needed more information out of the tape driver. So that was the primary motivation behind adding the additional features. (Other features I implemented using SCSI passthrough.) He is correct that it runs with FUSE, although it can be linked into an application as a library as well. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 19:07:38 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 83B58CA7; Mon, 2 Mar 2015 19:07:38 +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 53479653; Mon, 2 Mar 2015 19:07:37 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 211FB6FEC ; Mon, 2 Mar 2015 19:07:36 +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: <20150302172846.GB87055@mithlond.kdm.org> Date: Mon, 2 Mar 2015 14:07:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <12EED94D-CC9D-44C4-91C2-62C8A51B839B@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@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: Mon, 02 Mar 2015 19:07:38 -0000 > On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry wrote: >=20 > On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: >>=20 >>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry = wrote: >>>=20 >>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: >>>>=20 >>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>>>>>=20 >>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>>>>>=20 >>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>>>>>=20 >>>>>>>> Device { >>>>>>>> Name =3D DLT >>>>>>>> Description =3D "QUANTUM DLT7000 1624" >>>>>>>> Media Type =3D DLT >>>>>>>> Archive Device =3D /dev/nsa1 >>>>>>>>=20 >>>>>>>> Autochanger =3D YES >>>>>>>> Drive Index =3D 0 >>>>>>>>=20 >>>>>>>> Offline On Unmount =3D no >>>>>>>> Hardware End of Medium =3D yes >>>>>>>> BSF at EOM =3D yes >>>>>>>> Backward Space Record =3D no >>>>>>>> Fast Forward Space File =3D no >>>>>>>> TWO EOF =3D yes >>>>>>>> } >>>>>>>>=20 >>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) = has a btape test on this same model. >>>>>>>>=20 >>>>>>>> Here's the test I ran tonight: >>>>>>>>=20 >>>>>>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>>>>>> Tape block granularity is 1024 bytes. >>>>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>> *test >>>>>>>>=20 >>>>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>>>>>=20 >>>>>>>> I'm going to write 10000 records and an EOF >>>>>>>> then write 10000 records and an EOF, then rewind, >>>>>>>> and re-read the data to verify that it is correct. >>>>>>>>=20 >>>>>>>> This is an *essential* feature ... >>>>>>>>=20 >>>>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1210-0 Rewind OK. >>>>>>>> 10000 blocks re-read correctly. >>>>>>>> Got EOF on tape. >>>>>>>> 10000 blocks re-read correctly. >>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>=20 >>>>>>>> btape: btape.c:1277-0 Block position test >>>>>>>> btape: btape.c:1289-0 Rewind OK. >>>>>>>> Reposition to file:block 0:4 >>>>>>>> Block 5 re-read correctly. >>>>>>>> Reposition to file:block 0:200 >>>>>>>> Block 201 re-read correctly. >>>>>>>> Reposition to file:block 0:9999 >>>>>>>> Block 10000 re-read correctly. >>>>>>>> Reposition to file:block 1:0 >>>>>>>> Block 10001 re-read correctly. >>>>>>>> Reposition to file:block 1:600 >>>>>>>> Block 10601 re-read correctly. >>>>>>>> Reposition to file:block 1:9999 >>>>>>>> Block 20000 re-read correctly. >>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>>>=20 >>>>>>>> This test is essential to Bacula. >>>>>>>>=20 >>>>>>>> I'm going to write one record in file 0, >>>>>>>> two records in file 1, >>>>>>>> and three records in file 2 >>>>>>>>=20 >>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>>>=20 >>>>>>> This is the critical piece. The test moves the tape to the end = of the >>>>>>> medium. With hardware position information, you can tell what = filemark >>>>>>> you're on. Without it, you can't. >>>>>>>=20 >>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on = "DLT" (/dev/nsa1). ERR=3DNo error: 0. >>>>>>>> We should be in file 3. I am at file 0. This is NOT correct!!!! >>>>>>>>=20 >>>>>>>> Append test failed. Attempting again. >>>>>>>> Setting "Hardware End of Medium =3D no >>>>>>>> and "Fast Forward Space File =3D no >>>>>>>> and retrying append test. >>>>>>>=20 >>>>>>> This is not surprsing, given that the drive doesn't support long = read >>>>>>> position data. (It's a SCSI-2 device.) So that means that = Bacula will >>>>>>> need to do it manually. >>>>>>=20 >>>>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 = but that >>>>>> tape library is hooked up to a different computer and was doing = backups today. >>>>>=20 >>>>> So, here is one thing that we can try to see whether these drives = support >>>>> long position information, even though they only claim to be = SCSI-2. If >>>>> they do, we can potentially add a quirk (or autodetection) to = enable it. >>>>> The code currently doesn't bother asking drives that claim to be = SCSI-2 >>>>> for long position information. (Because that feature was added in = the >>>>> SSC spec, which came after SCSI-2.) >>>>>=20 >>>>> Issue a READ POSITION with the short form specified: >>>>>=20 >>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>=20 >>>>> Issue a READ POSITION with the vendor-specific block numbers: >>>>>=20 >>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>=20 >>>>> Issue a READ POSITION with the long form data: >>>>>=20 >>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >>>>>=20 >>>>> If it supports the last one, then I can put a quirk (or = autodetection) in >>>>> the driver and Bacula will get the hardware filemarks. You should = try this >>>>> on your SDLT as well. It may well support it. >>>>=20 >>>> Sadly, no: >>>>=20 >>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i = 20 - |hd >>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000010 00 00 00 00 |....| >>>> 00000014 >>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i = 20 - |hd >>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000010 00 00 00 00 |....| >>>> 00000014 >>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i = 32 - |hd >>>> camcontrol: error sending command >>>> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 = 00=20 >>>> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error >>>> (pass2:ahc0:0:2:0): SCSI status: Check Condition >>>> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid = field in CDB) >>>> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid >>>> [root@cuppy:~] #=20 >>>=20 >>> Okay. Not too surprising I suppose. Does this mean much to you? Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f I'm having trouble with labeling barcodes from Bacula and the above is = seen in /var/log/messages >>>=20 >>>> The SDLT server is on 9.3 though: >>>>=20 >>>> [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >>>> cam_lookup_pass: No such file or directory >>>> cam_lookup_pass: either the pass driver isn't in your kernel >>>> cam_lookup_pass: or sa1 doesn't exist >>>> [root@knew:/usr/home/dan] # uname -a >>>> FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 = #0: Tue Feb 24 21:28:03 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >>>> [root@knew:/usr/home/dan] #=20 >>>>=20 >>>>=20 >>>> It took me a while to figure that out... there is no sa1 on *this* = system. >>>>=20 >>>> But, my SDLT: >>>>=20 >>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000010 00 00 00 00 |....| >>>> 00000014 >>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000010 00 00 00 00 |....| >>>> 00000014 >>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 = 0 0 0 0" -i 32 - |hd >>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>> 00000020 >>>> [root@knew:/usr/home/dan] #=20 >>>=20 >>> Just to confirm, can you send the output of: >>>=20 >>> camcontrol inquiry sa0 -v >>>=20 >>> I want to make certain it reports that it is SCSI-2. If so, I'll = change >>> the check in the driver to try asking for long position information = on >>> SCSI-2 devices. If it fails, it'll fall back to the regular method. >>=20 >> [dan@knew:~] $ sudo camcontrol inquiry sa0 -v >> pass10: Removable Sequential Access SCSI-2 = device=20 >> pass10: Serial Number CXB46H0716 =20 >> pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) >> [dan@knew:~] $=20 >=20 > Okay. Doing the check doesn't cause any problems on my collection of = old > tape drives, so I'll go ahead and enable checking on SCSI-2 devices. >=20 > The primary thing is just making sure it doesn't cause tape drive to = choke > if we request long position information. It doesn't appear to be an > issue. If we do run into one, we can put in a quirk. >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 19:47:10 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 BAA739BD; Mon, 2 Mar 2015 19:47:10 +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 89FF9B8C; Mon, 2 Mar 2015 19:47:09 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 9871C6FF3 ; Mon, 2 Mar 2015 19:47:08 +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: <12EED94D-CC9D-44C4-91C2-62C8A51B839B@langille.org> Date: Mon, 2 Mar 2015 14:47:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@mithlond.kdm.org> <12EED94D-CC9D-44C4-91C2-62C8A51B839B@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: Mon, 02 Mar 2015 19:47:10 -0000 > On Mar 2, 2015, at 2:07 PM, Dan Langille wrote: >=20 >=20 >> On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry = wrote: >>=20 >> On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: >>>=20 >>>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry = wrote: >>>>=20 >>>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: >>>>>=20 >>>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry = wrote: >>>>>>=20 >>>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>>>>>>=20 >>>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>>>>>>=20 >>>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>>>>>>=20 >>>>>>>>> Device { >>>>>>>>> Name =3D DLT >>>>>>>>> Description =3D "QUANTUM DLT7000 1624" >>>>>>>>> Media Type =3D DLT >>>>>>>>> Archive Device =3D /dev/nsa1 >>>>>>>>>=20 >>>>>>>>> Autochanger =3D YES >>>>>>>>> Drive Index =3D 0 >>>>>>>>>=20 >>>>>>>>> Offline On Unmount =3D no >>>>>>>>> Hardware End of Medium =3D yes >>>>>>>>> BSF at EOM =3D yes >>>>>>>>> Backward Space Record =3D no >>>>>>>>> Fast Forward Space File =3D no >>>>>>>>> TWO EOF =3D yes >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) = has a btape test on this same model. >>>>>>>>>=20 >>>>>>>>> Here's the test I ran tonight: >>>>>>>>>=20 >>>>>>>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>>>>>>> Tape block granularity is 1024 bytes. >>>>>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>> *test >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>>>>>>=20 >>>>>>>>> I'm going to write 10000 records and an EOF >>>>>>>>> then write 10000 records and an EOF, then rewind, >>>>>>>>> and re-read the data to verify that it is correct. >>>>>>>>>=20 >>>>>>>>> This is an *essential* feature ... >>>>>>>>>=20 >>>>>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1210-0 Rewind OK. >>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>> Got EOF on tape. >>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>>=20 >>>>>>>>> btape: btape.c:1277-0 Block position test >>>>>>>>> btape: btape.c:1289-0 Rewind OK. >>>>>>>>> Reposition to file:block 0:4 >>>>>>>>> Block 5 re-read correctly. >>>>>>>>> Reposition to file:block 0:200 >>>>>>>>> Block 201 re-read correctly. >>>>>>>>> Reposition to file:block 0:9999 >>>>>>>>> Block 10000 re-read correctly. >>>>>>>>> Reposition to file:block 1:0 >>>>>>>>> Block 10001 re-read correctly. >>>>>>>>> Reposition to file:block 1:600 >>>>>>>>> Block 10601 re-read correctly. >>>>>>>>> Reposition to file:block 1:9999 >>>>>>>>> Block 20000 re-read correctly. >>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>>>>=20 >>>>>>>>> This test is essential to Bacula. >>>>>>>>>=20 >>>>>>>>> I'm going to write one record in file 0, >>>>>>>>> two records in file 1, >>>>>>>>> and three records in file 2 >>>>>>>>>=20 >>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>>>>=20 >>>>>>>> This is the critical piece. The test moves the tape to the end = of the >>>>>>>> medium. With hardware position information, you can tell what = filemark >>>>>>>> you're on. Without it, you can't. >>>>>>>>=20 >>>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on = "DLT" (/dev/nsa1). ERR=3DNo error: 0. >>>>>>>>> We should be in file 3. I am at file 0. This is NOT = correct!!!! >>>>>>>>>=20 >>>>>>>>> Append test failed. Attempting again. >>>>>>>>> Setting "Hardware End of Medium =3D no >>>>>>>>> and "Fast Forward Space File =3D no >>>>>>>>> and retrying append test. >>>>>>>>=20 >>>>>>>> This is not surprsing, given that the drive doesn't support = long read >>>>>>>> position data. (It's a SCSI-2 device.) So that means that = Bacula will >>>>>>>> need to do it manually. >>>>>>>=20 >>>>>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 = but that >>>>>>> tape library is hooked up to a different computer and was doing = backups today. >>>>>>=20 >>>>>> So, here is one thing that we can try to see whether these drives = support >>>>>> long position information, even though they only claim to be = SCSI-2. If >>>>>> they do, we can potentially add a quirk (or autodetection) to = enable it. >>>>>> The code currently doesn't bother asking drives that claim to be = SCSI-2 >>>>>> for long position information. (Because that feature was added = in the >>>>>> SSC spec, which came after SCSI-2.) >>>>>>=20 >>>>>> Issue a READ POSITION with the short form specified: >>>>>>=20 >>>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>=20 >>>>>> Issue a READ POSITION with the vendor-specific block numbers: >>>>>>=20 >>>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>=20 >>>>>> Issue a READ POSITION with the long form data: >>>>>>=20 >>>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >>>>>>=20 >>>>>> If it supports the last one, then I can put a quirk (or = autodetection) in >>>>>> the driver and Bacula will get the hardware filemarks. You = should try this >>>>>> on your SDLT as well. It may well support it. >>>>>=20 >>>>> Sadly, no: >>>>>=20 >>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" = -i 20 - |hd >>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000010 00 00 00 00 |....| >>>>> 00000014 >>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" = -i 20 - |hd >>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000010 00 00 00 00 |....| >>>>> 00000014 >>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" = -i 32 - |hd >>>>> camcontrol: error sending command >>>>> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 = 00=20 >>>>> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error >>>>> (pass2:ahc0:0:2:0): SCSI status: Check Condition >>>>> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid = field in CDB) >>>>> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid >>>>> [root@cuppy:~] #=20 >>>>=20 >>>> Okay. Not too surprising I suppose. >=20 >=20 > Does this mean much to you? >=20 > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f > Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >=20 >=20 > I'm having trouble with labeling barcodes from Bacula and the above is = seen in /var/log/messages The barcodes issue is resolved. I changed to using drive 0 instead of = drive 1, now that we have both drives. *label barcodes slots=3D3,4 The defined Storage resources are: 1: File1 2: OldTL891 Select Storage resource (1-2): 2 Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... 3306 Issuing autochanger "slots" command. Device "DTL03" has 10 slots. Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... 3306 Issuing autochanger "list" command. The following Volumes will be labeled: Slot Volume =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3 FAI261 4 FAI262 Do you want to label these Volumes? (yes|no): yes Defined Pools: 1: Default 2: File 3: MYDLT 4: Scratch Select the Pool (1-4): 4 Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... Sending label command for Volume "FAI261" Slot 3 ... 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI261" Device=3D"DTL03"= (/dev/nsa0) Catalog record for Volume "FAI261", Slot 3 successfully created. Sending label command for Volume "FAI262" Slot 4 ... 3307 Issuing autochanger "unload slot 3, drive 0" command. 3304 Issuing autochanger "load slot 4, drive 0" command. 3305 Autochanger "load slot 4, drive 0", status is OK. 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI262" Device=3D"DTL03"= (/dev/nsa0) Catalog record for Volume "FAI262", Slot 4 successfully created. *list volumes Pool: Default No results to list. Pool: File = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= | mediaid | volumename | volstatus | enabled | volbytes | volfiles | = volretention | recycle | slot | inchanger | mediatype | lastwritten = | = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= | 1 | Vol-0001 | Append | 1 | 19,835,982 | 0 | = 31,536,000 | 1 | 0 | 0 | File1 | 2015-03-02 = 17:50:40 | | 2 | Vol-0002 | Append | 1 | 0 | 0 | = 31,536,000 | 1 | 0 | 0 | DLT | = | = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= Pool: MYDLT No results to list. Pool: Scratch = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ | mediaid | volumename | volstatus | enabled | volbytes | volfiles | = volretention | recycle | slot | inchanger | mediatype | lastwritten | = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ | 4 | FAI260 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 1 | 1 | DLT | | | 5 | FAI263 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 2 | 1 | DLT | | | 7 | FAI261 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 3 | 1 | DLT | | | 8 | FAI262 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 4 | 1 | DLT | | = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ * But this is what arrives in /var/log/messages during the above: Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f Mar 2 20:29:06 cuppy kernel: Filtered to period 19, offset f Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f Mar 2 20:30:59 cuppy kernel: Filtered to period 19, offset f Mar 2 20:30:59 cuppy kernel: xpt_release_devq(): requested 1 > present = 0 Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f Mar 2 20:31:07 cuppy kernel: Filtered to period 19, offset f Anything to be concerned about? >=20 >>>>=20 >>>>> The SDLT server is on 9.3 though: >>>>>=20 >>>>> [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>>> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >>>>> cam_lookup_pass: No such file or directory >>>>> cam_lookup_pass: either the pass driver isn't in your kernel >>>>> cam_lookup_pass: or sa1 doesn't exist >>>>> [root@knew:/usr/home/dan] # uname -a >>>>> FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD = 9.3-RELEASE-p10 #0: Tue Feb 24 21:28:03 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >>>>> [root@knew:/usr/home/dan] #=20 >>>>>=20 >>>>>=20 >>>>> It took me a while to figure that out... there is no sa1 on *this* = system. >>>>>=20 >>>>> But, my SDLT: >>>>>=20 >>>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000010 00 00 00 00 |....| >>>>> 00000014 >>>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 = 0 0 0 0" -i 20 - |hd >>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000010 00 00 00 00 |....| >>>>> 00000014 >>>>> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 = 0 0 0 0" -i 32 - |hd >>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>> 00000020 >>>>> [root@knew:/usr/home/dan] #=20 >>>>=20 >>>> Just to confirm, can you send the output of: >>>>=20 >>>> camcontrol inquiry sa0 -v >>>>=20 >>>> I want to make certain it reports that it is SCSI-2. If so, I'll = change >>>> the check in the driver to try asking for long position information = on >>>> SCSI-2 devices. If it fails, it'll fall back to the regular = method. >>>=20 >>> [dan@knew:~] $ sudo camcontrol inquiry sa0 -v >>> pass10: Removable Sequential Access SCSI-2 = device=20 >>> pass10: Serial Number CXB46H0716 =20 >>> pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) >>> [dan@knew:~] $=20 >>=20 >> Okay. Doing the check doesn't cause any problems on my collection of = old >> tape drives, so I'll go ahead and enable checking on SCSI-2 devices. >>=20 >> The primary thing is just making sure it doesn't cause tape drive to = choke >> if we request long position information. It doesn't appear to be an >> issue. If we do run into one, we can put in a quirk. >>=20 >> Ken >> --=20 >> Kenneth Merry >> ken@FreeBSD.ORG >=20 > =E2=80=94=20 > Dan Langille > http://langille.org/ >=20 >=20 >=20 >=20 >=20 =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 20:02:05 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 163A1407 for ; Mon, 2 Mar 2015 20:02:05 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.fisglobal.com", Issuer "VeriSign Class 3 Secure Server CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2337DA7 for ; Mon, 2 Mar 2015 20:02:04 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.16]) by ltcfislmsgpsa03.fnfis.com (8.14.7/8.14.7) with ESMTP id t22JpUIx019293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 2 Mar 2015 13:51:30 -0600 Received: from [10.242.182.122] (10.242.182.122) by smtp.fisglobal.com (10.132.206.16) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 2 Mar 2015 13:51:29 -0600 Message-ID: <54F4BF40.3000302@fisglobal.com> Date: Mon, 2 Mar 2015 11:51:28 -0800 From: "Robison, Dave" Reply-To: User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Subject: Regression since 8.4? Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.242.182.122] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-02_03:2015-03-02,2015-03-02,1970-01-01 signatures=0 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: Mon, 02 Mar 2015 20:02:05 -0000 Hiya, Running an HP Proliant DL380 G5. It has the HP Smart Array P400 card in it. I've got a mirror on the P400 for my base file systems. I have the other 6 drives in a RAIDZ setup. Also have a QLogic QLE 2532 card which has two NEC D1-10 RAID arrays connected into a single ZPool. I use this machine at work for backups. Everything was fine in FreeBSD 8.4. I upgraded to 9.3 and then to 10.1 a couple weekends ago. Since then the machine won't stay up more than a couple of days. When I power the machine off and reboot, it will not see the QLogic card or RAID arrays. I have to physically power down the entire system and RAIDs in order for it to boot properly. It's running the GENERIC kernel and freezes up with no core dump. This machine runs Bacula, Samba, netatalk. Before the upgrade this machine would run for hundreds of days uptime. Now it's more like 1-2 days. I'd downgrade back to 8.4, but now that I have upgraded the ZPools and file systems I don't think it will work with the older 8.4 any more. Looking for ideas where I should start looking for the culprit. I suspect the Smart Array P400 or the QLE 2532. Following is the dmesg.boot output, but the one thing that immediately catches my eye is this: (da3:ciss0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da3:ciss0:0:1:0): CAM status: SCSI Status Error (da3:ciss0:0:1:0): SCSI status: Check Condition (da3:ciss0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da3:ciss0:0:1:0): Error 22, Unretryable error (da4:ciss0:0:2:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da4:ciss0:0:2:0): CAM status: SCSI Status Error (da4:ciss0:0:2:0): SCSI status: Check Condition (da4:ciss0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da4:ciss0:0:2:0): Error 22, Unretryable error (da5:ciss0:0:3:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da5:ciss0:0:3:0): CAM status: SCSI Status Error (da5:ciss0:0:3:0): SCSI status: Check Condition (da5:ciss0:0:3:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da5:ciss0:0:3:0): Error 22, Unretryable error (da6:ciss0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da6:ciss0:0:4:0): CAM status: SCSI Status Error (da6:ciss0:0:4:0): SCSI status: Check Condition (da6:ciss0:0:4:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da6:ciss0:0:4:0): Error 22, Unretryable error (da7:ciss0:0:5:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da7:ciss0:0:5:0): CAM status: SCSI Status Error (da7:ciss0:0:5:0): SCSI status: Check Condition (da7:ciss0:0:5:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da7:ciss0:0:5:0): Error 22, Unretryable error (da8:ciss0:0:6:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da8:ciss0:0:6:0): CAM status: SCSI Status Error (da8:ciss0:0:6:0): SCSI status: Check Condition (da8:ciss0:0:6:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da8:ciss0:0:6:0): Error 22, Unretryable error Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-RELEASE-p5 #0: Tue Jan 27 08:55:07 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Intel(R) Xeon(R) CPU 5160 @ 3.00GHz (3000.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 0x6 Model = 0xf Stepping = 11 Features=0xbfebfbff Features2=0x4e3bd AMD Features=0x20100800 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8269488128 (7886 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 32, using default 16 (20130823/tbfadt-682) ACPI BIOS Warning (bug): Invalid length for FADT/Pm2ControlBlock: 32, using default 8 (20130823/tbfadt-682) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 ACPI Warning: \134_SB_.PCI0.PT02._PRT: Return Package has no elements (empty) (20130823/nsprepkg-137) pci9: on pcib1 pcib2: at device 0.0 on pci9 pci10: on pcib2 pcib3: at device 0.0 on pci10 pci11: on pcib3 pcib4: at device 1.0 on pci10 pci14: on pcib4 isp0: port 0x5000-0x50ff mem 0xfdff0000-0xfdff3fff,0xfde00000-0xfdefffff irq 17 at device 0.0 on pci14 isp1: port 0x5400-0x54ff mem 0xfddf0000-0xfddf3fff,0xfdc00000-0xfdcfffff irq 18 at device 0.1 on pci14 pcib5: at device 2.0 on pci10 pci17: on pcib5 pcib6: at device 0.3 on pci9 pci18: on pcib6 pcib7: at device 3.0 on pci0 pci6: on pcib7 ciss0: port 0x4000-0x40ff mem 0xfda00000-0xfdafffff,0xfd9f0000-0xfd9f0fff irq 18 at device 0.0 on pci6 ciss0: PERFORMANT Transport pcib8: at device 4.0 on pci0 pci19: on pcib8 pcib9: at device 5.0 on pci0 pci22: on pcib9 pcib10: at device 6.0 on pci0 pci23: on pcib10 pcib11: at device 7.0 on pci0 pci26: on pcib11 pcib12: at device 28.0 on pci0 pci2: on pcib12 pcib13: at device 0.0 on pci2 pci3: on pcib13 bce0: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 bce0: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled but not running! miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce0: Ethernet address: 00:1c:c4:ec:75:3a bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (1.9.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) Coal (RX:6,6,18,18; TX:20,20,80,80) pcib14: at device 28.1 on pci0 pci4: on pcib14 pcib15: at device 0.0 on pci4 pci5: on pcib15 bce1: mem 0xfa000000-0xfbffffff irq 17 at device 0.0 on pci5 bce1: /usr/src/sys/dev/bce/if_bce.c(1247): Management firmware enabled but not running! miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bce1: Ethernet address: 00:1c:c4:ec:75:38 bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (1.9.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!) Coal (RX:6,6,18,18; TX:20,20,80,80) uhci0: port 0x1000-0x101f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0x1020-0x103f irq 17 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0x1040-0x105f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: port 0x1060-0x107f irq 19 at device 29.3 on pci0 usbus3 on uhci3 ehci0: mem 0xf7df0000-0xf7df03ff irq 16 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib16: at device 30.0 on pci0 pci1: on pcib16 vgapci0: port 0x3000-0x30ff mem 0xd8000000-0xdfffffff,0xf7ff0000-0xf7ffffff irq 23 at device 3.0 on pci1 vgapci0: Boot video device uhci4: port 0x3800-0x381f irq 22 at device 4.4 on pci1 usbus5 on uhci4 pci1: at device 4.6 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f irq 17 at device 31.1 on pci0 ata0: at channel 0 on atapci0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xc0000-0xcafff,0xd1000-0xdf7ff,0xe6000-0xe7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 ppc0: cannot reserve I/O port range uart1: at port 0x2f8-0x2ff irq 3 on isa0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 92a092a0600092a device_attach: est1 attach returned 6 p4tcc1: on cpu1 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 usbus5: 12Mbps Full Speed USB v1.0 ugen1.1: at usbus1 uhub0: on usbus1 ugen0.1: at usbus0 uhub1: on usbus0 ugen3.1: at usbus3 uhub2: on usbus3 ugen2.1: at usbus2 uhub3: on usbus2 ugen5.1: <0x103c> at usbus5 uhub4: <0x103c UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus5 ugen4.1: at usbus4 uhub5: on usbus4 da2 at ciss0 bus 0 scbus2 target 0 lun 0 da2: Fixed Direct Access SCSI-5 device da2: Serial Number P61620F9VV88SR da2: 135.168MB/s transfers da2: Command Queueing enabled da2: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da0 at isp0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-4 device da0: Serial Number 0000934988650000 da0: 400.000MB/s transfers WWNN 0x200000169712094c WWPN 0x210000169712094c PortID 0xb3 da0: Command Queueing enabled da0: 8255488MB (16907239424 512 byte sectors: 255H 63S/T 1052426C) da3 at ciss0 bus 0 scbus2 target 1 lun 0 da3: Fixed Direct Access SCSI-5 device da3: Serial Number P61620F9VV88SR da3: 135.168MB/s transfers da3: Command Queueing enabled da3: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da1 at isp1 bus 0 scbus1 target 0 lun 0 da1: Fixed Direct Access SCSI-4 device da1: Serial Number 0000349001230000 da1: 400.000MB/s transfers WWNN 0x20000030138419c8 WWPN 0x21000030138419c8 PortID 0xcd da1: Command Queueing enabled da1: 4124672MB (8447328256 512 byte sectors: 255H 63S/T 525821C) da4 at ciss0 bus 0 scbus2 target 2 lun 0 da4: Fixed Direct Access SCSI-5 device da4: Serial Number P61620F9VV88SR da4: 135.168MB/s transfers da4: Command Queueing enabled da4: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da5 at ciss0 bus 0 scbus2 target 3 lun 0 da5: Fixed Direct Access SCSI-5 device da5: Serial Number P61620F9VV88SR da5: 135.168MB/s transfers da5: Command Queueing enabled da5: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da6 at ciss0 bus 0 scbus2 target 4 lun 0 da6: Fixed Direct Access SCSI-5 device da6: Serial Number P61620F9VV88SR da6: 135.168MB/s transfers da6: Command Queueing enabled da6: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da7 at ciss0 bus 0 scbus2 target 5 lun 0 da7: Fixed Direct Access SCSI-5 device da7: Serial Number P61620F9VV88SR da7: 135.168MB/s transfers da7: Command Queueing enabled da7: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) da8 at ciss0 bus 0 scbus2 target 6 lun 0 da8: Fixed Direct Access SCSI-5 device da8: Serial Number P61620F9VV88SR da8: 135.168MB/s transfers da8: Command Queueing enabled da8: 476908MB (976707632 512 byte sectors: 255H 32S/T 65535C) uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1500029482 Hz quality 1000 ugen5.2: at usbus5 ukbd0: on usbus5 kbd2 at ukbd0 ugen5.3: at usbus5 uhub6: on usbus5 uhub5: 8 ports with 8 removable, self powered uhub6: 7 ports with 7 removable, self powered ugen3.2: at usbus3 ukbd1: on usbus3 kbd3 at ukbd1 isp1: isp_watchdog: timeout for handle 0x2f2000, recovered during interrupt GEOM_PART: integrity check failed (da3, MBR) GEOM_PART: integrity check failed (da4, BSD) GEOM_PART: integrity check failed (da7, BSD) GEOM_PART: integrity check failed (da8, BSD) Trying to mount root from ufs:/dev/da2s1a [rw]... WARNING: / was not properly dismounted ZFS filesystem version: 5 ZFS storage pool version: features support (5000) (da3:ciss0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da3:ciss0:0:1:0): CAM status: SCSI Status Error (da3:ciss0:0:1:0): SCSI status: Check Condition (da3:ciss0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da3:ciss0:0:1:0): Error 22, Unretryable error (da4:ciss0:0:2:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da4:ciss0:0:2:0): CAM status: SCSI Status Error (da4:ciss0:0:2:0): SCSI status: Check Condition (da4:ciss0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da4:ciss0:0:2:0): Error 22, Unretryable error (da5:ciss0:0:3:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da5:ciss0:0:3:0): CAM status: SCSI Status Error (da5:ciss0:0:3:0): SCSI status: Check Condition (da5:ciss0:0:3:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da5:ciss0:0:3:0): Error 22, Unretryable error (da6:ciss0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da6:ciss0:0:4:0): CAM status: SCSI Status Error (da6:ciss0:0:4:0): SCSI status: Check Condition (da6:ciss0:0:4:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da6:ciss0:0:4:0): Error 22, Unretryable error (da7:ciss0:0:5:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da7:ciss0:0:5:0): CAM status: SCSI Status Error (da7:ciss0:0:5:0): SCSI status: Check Condition (da7:ciss0:0:5:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da7:ciss0:0:5:0): Error 22, Unretryable error (da8:ciss0:0:6:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da8:ciss0:0:6:0): CAM status: SCSI Status Error (da8:ciss0:0:6:0): SCSI status: Check Condition (da8:ciss0:0:6:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da8:ciss0:0:6:0): Error 22, Unretryable error WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted bce0: Gigabit link up! ums0: on usbus5 ums0: 3 buttons and [XY] coordinates ID=0 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled -------- Dave Robison Sales Solution Architect II FIS Banking Solutions 510/621-2089 (w) 530/518-5194 (c) 510/621-2020 (f) daver@vicor.com david.robison@fisglobal.com _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 21:34:38 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 BCC0DB0D; Mon, 2 Mar 2015 21:34:38 +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 8A5BFAA5; Mon, 2 Mar 2015 21:34:37 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 90CA81B3 ; Mon, 2 Mar 2015 21:34:35 +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: Date: Mon, 2 Mar 2015 16:34:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <95BCE742-8CC4-41FC-9FDD-D12C7A337951@langille.org> References: <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@mithlond.kdm.org> <12EED94D-CC9D-44C4-91C2-62C8A51B839B@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: Mon, 02 Mar 2015 21:34:38 -0000 > On Mar 2, 2015, at 2:47 PM, Dan Langille wrote: >=20 >=20 >> On Mar 2, 2015, at 2:07 PM, Dan Langille wrote: >>=20 >>=20 >>> On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry = wrote: >>>=20 >>> On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: >>>>=20 >>>>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry = wrote: >>>>>=20 >>>>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: >>>>>>=20 >>>>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry = wrote: >>>>>>>=20 >>>>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>>>>>>>=20 >>>>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>>>>>>>=20 >>>>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>>>>>>>=20 >>>>>>>>>> Device { >>>>>>>>>> Name =3D DLT >>>>>>>>>> Description =3D "QUANTUM DLT7000 1624" >>>>>>>>>> Media Type =3D DLT >>>>>>>>>> Archive Device =3D /dev/nsa1 >>>>>>>>>>=20 >>>>>>>>>> Autochanger =3D YES >>>>>>>>>> Drive Index =3D 0 >>>>>>>>>>=20 >>>>>>>>>> Offline On Unmount =3D no >>>>>>>>>> Hardware End of Medium =3D yes >>>>>>>>>> BSF at EOM =3D yes >>>>>>>>>> Backward Space Record =3D no >>>>>>>>>> Fast Forward Space File =3D no >>>>>>>>>> TWO EOF =3D yes >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from = 2006) has a btape test on this same model. >>>>>>>>>>=20 >>>>>>>>>> Here's the test I ran tonight: >>>>>>>>>>=20 >>>>>>>>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>>>>>>>> Tape block granularity is 1024 bytes. >>>>>>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>>> *test >>>>>>>>>>=20 >>>>>>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>>>>>>>=20 >>>>>>>>>> I'm going to write 10000 records and an EOF >>>>>>>>>> then write 10000 records and an EOF, then rewind, >>>>>>>>>> and re-read the data to verify that it is correct. >>>>>>>>>>=20 >>>>>>>>>> This is an *essential* feature ... >>>>>>>>>>=20 >>>>>>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1210-0 Rewind OK. >>>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>>> Got EOF on tape. >>>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>>>=20 >>>>>>>>>> btape: btape.c:1277-0 Block position test >>>>>>>>>> btape: btape.c:1289-0 Rewind OK. >>>>>>>>>> Reposition to file:block 0:4 >>>>>>>>>> Block 5 re-read correctly. >>>>>>>>>> Reposition to file:block 0:200 >>>>>>>>>> Block 201 re-read correctly. >>>>>>>>>> Reposition to file:block 0:9999 >>>>>>>>>> Block 10000 re-read correctly. >>>>>>>>>> Reposition to file:block 1:0 >>>>>>>>>> Block 10001 re-read correctly. >>>>>>>>>> Reposition to file:block 1:600 >>>>>>>>>> Block 10601 re-read correctly. >>>>>>>>>> Reposition to file:block 1:9999 >>>>>>>>>> Block 20000 re-read correctly. >>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read test = =3D=3D=3D >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>>>>>=20 >>>>>>>>>> This test is essential to Bacula. >>>>>>>>>>=20 >>>>>>>>>> I'm going to write one record in file 0, >>>>>>>>>> two records in file 1, >>>>>>>>>> and three records in file 2 >>>>>>>>>>=20 >>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>>>>>=20 >>>>>>>>> This is the critical piece. The test moves the tape to the = end of the >>>>>>>>> medium. With hardware position information, you can tell what = filemark >>>>>>>>> you're on. Without it, you can't. >>>>>>>>>=20 >>>>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on = "DLT" (/dev/nsa1). ERR=3DNo error: 0. >>>>>>>>>> We should be in file 3. I am at file 0. This is NOT = correct!!!! >>>>>>>>>>=20 >>>>>>>>>> Append test failed. Attempting again. >>>>>>>>>> Setting "Hardware End of Medium =3D no >>>>>>>>>> and "Fast Forward Space File =3D no >>>>>>>>>> and retrying append test. >>>>>>>>>=20 >>>>>>>>> This is not surprsing, given that the drive doesn't support = long read >>>>>>>>> position data. (It's a SCSI-2 device.) So that means that = Bacula will >>>>>>>>> need to do it manually. >>>>>>>>=20 >>>>>>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 = but that >>>>>>>> tape library is hooked up to a different computer and was doing = backups today. >>>>>>>=20 >>>>>>> So, here is one thing that we can try to see whether these = drives support >>>>>>> long position information, even though they only claim to be = SCSI-2. If >>>>>>> they do, we can potentially add a quirk (or autodetection) to = enable it. >>>>>>> The code currently doesn't bother asking drives that claim to be = SCSI-2 >>>>>>> for long position information. (Because that feature was added = in the >>>>>>> SSC spec, which came after SCSI-2.) >>>>>>>=20 >>>>>>> Issue a READ POSITION with the short form specified: >>>>>>>=20 >>>>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>>=20 >>>>>>> Issue a READ POSITION with the vendor-specific block numbers: >>>>>>>=20 >>>>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>>=20 >>>>>>> Issue a READ POSITION with the long form data: >>>>>>>=20 >>>>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >>>>>>>=20 >>>>>>> If it supports the last one, then I can put a quirk (or = autodetection) in >>>>>>> the driver and Bacula will get the hardware filemarks. You = should try this >>>>>>> on your SDLT as well. It may well support it. >>>>>>=20 >>>>>> Sadly, no: >>>>>>=20 >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" = -i 20 - |hd >>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>>> 00000010 00 00 00 00 = |....| >>>>>> 00000014 >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" = -i 20 - |hd >>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>>> 00000010 00 00 00 00 = |....| >>>>>> 00000014 >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" = -i 32 - |hd >>>>>> camcontrol: error sending command >>>>>> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 = 00 00=20 >>>>>> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error >>>>>> (pass2:ahc0:0:2:0): SCSI status: Check Condition >>>>>> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid = field in CDB) >>>>>> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid >>>>>> [root@cuppy:~] #=20 >>>>>=20 >>>>> Okay. Not too surprising I suppose. >>=20 >>=20 >> Does this mean much to you? >>=20 >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, = offset f >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >>=20 >>=20 >> I'm having trouble with labeling barcodes from Bacula and the above = is seen in /var/log/messages >=20 > The barcodes issue is resolved. I changed to using drive 0 instead of = drive 1, now that we have both drives. >=20 > *label barcodes slots=3D3,4 > The defined Storage resources are: > 1: File1 > 2: OldTL891 > Select Storage resource (1-2): 2 > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > 3306 Issuing autochanger "slots" command. > Device "DTL03" has 10 slots. > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > 3306 Issuing autochanger "list" command. > The following Volumes will be labeled: > Slot Volume > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3 FAI261 > 4 FAI262 > Do you want to label these Volumes? (yes|no): yes > Defined Pools: > 1: Default > 2: File > 3: MYDLT > 4: Scratch > Select the Pool (1-4): 4 > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > Sending label command for Volume "FAI261" Slot 3 ... > 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI261" = Device=3D"DTL03" (/dev/nsa0) > Catalog record for Volume "FAI261", Slot 3 successfully created. > Sending label command for Volume "FAI262" Slot 4 ... > 3307 Issuing autochanger "unload slot 3, drive 0" command. > 3304 Issuing autochanger "load slot 4, drive 0" command. > 3305 Autochanger "load slot 4, drive 0", status is OK. > 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI262" = Device=3D"DTL03" (/dev/nsa0) > Catalog record for Volume "FAI262", Slot 4 successfully created. > *list volumes > Pool: Default > No results to list. > Pool: File > = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= > | mediaid | volumename | volstatus | enabled | volbytes | volfiles | = volretention | recycle | slot | inchanger | mediatype | lastwritten = | > = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= > | 1 | Vol-0001 | Append | 1 | 19,835,982 | 0 | = 31,536,000 | 1 | 0 | 0 | File1 | 2015-03-02 = 17:50:40 | > | 2 | Vol-0002 | Append | 1 | 0 | 0 | = 31,536,000 | 1 | 0 | 0 | DLT | = | > = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= > Pool: MYDLT > No results to list. > Pool: Scratch > = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ > | mediaid | volumename | volstatus | enabled | volbytes | volfiles | = volretention | recycle | slot | inchanger | mediatype | lastwritten | > = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ > | 4 | FAI260 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 1 | 1 | DLT | | > | 5 | FAI263 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 2 | 1 | DLT | | > | 7 | FAI261 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 3 | 1 | DLT | | > | 8 | FAI262 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 4 | 1 | DLT | | > = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ > * >=20 > But this is what arrives in /var/log/messages during the above: >=20 > Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f > Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f > Mar 2 20:29:06 cuppy kernel: Filtered to period 19, offset f > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f > Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f > Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f > Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f > Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f > Mar 2 20:30:59 cuppy kernel: Filtered to period 19, offset f > Mar 2 20:30:59 cuppy kernel: xpt_release_devq(): requested 1 > = present 0 > Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f > Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f > Mar 2 20:31:07 cuppy kernel: Filtered to period 19, offset f >=20 > Anything to be concerned about? When adding a 2nd job to a tape: 02-Mar 21:29 cuppy-sd JobId 19: Error: Unable to position to end of data = on tape device "DTL03" (/dev/nsa0): ERR=3Dtape_dev.c:345 ioctl MTIOCGET = error on "DTL03" (/dev/nsa0). ERR=3DNo error: 0. I've gotten this on three consecutive tapes. NOTE: These *are* tapes I = no longer use because of higher rates of corrected errors. The problem seems to be locating the end of the data. I can run a 4 or 5 jobs in a row, but if I restore a job, then add a = job, it fails with the above message. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 21:42:44 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 98DDF57F; Mon, 2 Mar 2015 21:42:44 +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 40D9CC15; Mon, 2 Mar 2015 21:42:44 +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 t22LgeEk091238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 14:42:40 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t22LgehR091237; Mon, 2 Mar 2015 14:42:40 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 14:42:40 -0700 From: "Kenneth D. Merry" To: Dan Langille Subject: Re: sa(4) driver changes available for test Message-ID: <20150302214240.GA91133@mithlond.kdm.org> References: <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@mithlond.kdm.org> <12EED94D-CC9D-44C4-91C2-62C8A51B839B@langille.org> <95BCE742-8CC4-41FC-9FDD-D12C7A337951@langille.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <95BCE742-8CC4-41FC-9FDD-D12C7A337951@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]); Mon, 02 Mar 2015 14:42:40 -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: Mon, 02 Mar 2015 21:42:44 -0000 On Mon, Mar 02, 2015 at 16:34:34 -0500, Dan Langille wrote: > > > On Mar 2, 2015, at 2:47 PM, Dan Langille wrote: > > > > > >> On Mar 2, 2015, at 2:07 PM, Dan Langille wrote: > >> > >> > >>> On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry wrote: > >>> > >>> On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: > >>>> > >>>>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry wrote: > >>>>> > >>>>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: > >>>>>> > >>>>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry wrote: > >>>>>>> > >>>>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: > >>>>>>>> > >>>>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry wrote: > >>>>>>>>> > >>>>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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. > >>>>>>>>>>> > >>>>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf > >>>>>>>>>> > >>>>>>>>>> Device { > >>>>>>>>>> Name = DLT > >>>>>>>>>> Description = "QUANTUM DLT7000 1624" > >>>>>>>>>> Media Type = DLT > >>>>>>>>>> Archive Device = /dev/nsa1 > >>>>>>>>>> > >>>>>>>>>> Autochanger = YES > >>>>>>>>>> Drive Index = 0 > >>>>>>>>>> > >>>>>>>>>> Offline On Unmount = no > >>>>>>>>>> Hardware End of Medium = yes > >>>>>>>>>> BSF at EOM = yes > >>>>>>>>>> Backward Space Record = no > >>>>>>>>>> Fast Forward Space File = no > >>>>>>>>>> TWO EOF = yes > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model. > >>>>>>>>>> > >>>>>>>>>> Here's the test I ran tonight: > >>>>>>>>>> > >>>>>>>>>> [root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 > >>>>>>>>>> Tape block granularity is 1024 bytes. > >>>>>>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. > >>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>>>>>>>> *test > >>>>>>>>>> > >>>>>>>>>> === Write, rewind, and re-read test === > >>>>>>>>>> > >>>>>>>>>> I'm going to write 10000 records and an EOF > >>>>>>>>>> then write 10000 records and an EOF, then rewind, > >>>>>>>>>> and re-read the data to verify that it is correct. > >>>>>>>>>> > >>>>>>>>>> This is an *essential* feature ... > >>>>>>>>>> > >>>>>>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1210-0 Rewind OK. > >>>>>>>>>> 10000 blocks re-read correctly. > >>>>>>>>>> Got EOF on tape. > >>>>>>>>>> 10000 blocks re-read correctly. > >>>>>>>>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>>>>>>>> > >>>>>>>>>> btape: btape.c:1277-0 Block position test > >>>>>>>>>> btape: btape.c:1289-0 Rewind OK. > >>>>>>>>>> Reposition to file:block 0:4 > >>>>>>>>>> Block 5 re-read correctly. > >>>>>>>>>> Reposition to file:block 0:200 > >>>>>>>>>> Block 201 re-read correctly. > >>>>>>>>>> Reposition to file:block 0:9999 > >>>>>>>>>> Block 10000 re-read correctly. > >>>>>>>>>> Reposition to file:block 1:0 > >>>>>>>>>> Block 10001 re-read correctly. > >>>>>>>>>> Reposition to file:block 1:600 > >>>>>>>>>> Block 10601 re-read correctly. > >>>>>>>>>> Reposition to file:block 1:9999 > >>>>>>>>>> Block 20000 re-read correctly. > >>>>>>>>>> === Test Succeeded. End Write, rewind, and re-read test === > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> === Append files test === > >>>>>>>>>> > >>>>>>>>>> This test is essential to Bacula. > >>>>>>>>>> > >>>>>>>>>> I'm going to write one record in file 0, > >>>>>>>>>> two records in file 1, > >>>>>>>>>> and three records in file 2 > >>>>>>>>>> > >>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. > >>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK > >>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) > >>>>>>>>>> btape: btape.c:1420-0 Now moving to end of medium. > >>>>>>>>> > >>>>>>>>> This is the critical piece. The test moves the tape to the end of the > >>>>>>>>> medium. With hardware position information, you can tell what filemark > >>>>>>>>> you're on. Without it, you can't. > >>>>>>>>> > >>>>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0. > >>>>>>>>>> We should be in file 3. I am at file 0. This is NOT correct!!!! > >>>>>>>>>> > >>>>>>>>>> Append test failed. Attempting again. > >>>>>>>>>> Setting "Hardware End of Medium = no > >>>>>>>>>> and "Fast Forward Space File = no > >>>>>>>>>> and retrying append test. > >>>>>>>>> > >>>>>>>>> This is not surprsing, given that the drive doesn't support long read > >>>>>>>>> position data. (It's a SCSI-2 device.) So that means that Bacula will > >>>>>>>>> need to do it manually. > >>>>>>>> > >>>>>>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that > >>>>>>>> tape library is hooked up to a different computer and was doing backups today. > >>>>>>> > >>>>>>> So, here is one thing that we can try to see whether these drives support > >>>>>>> long position information, even though they only claim to be SCSI-2. If > >>>>>>> they do, we can potentially add a quirk (or autodetection) to enable it. > >>>>>>> The code currently doesn't bother asking drives that claim to be SCSI-2 > >>>>>>> for long position information. (Because that feature was added in the > >>>>>>> SSC spec, which came after SCSI-2.) > >>>>>>> > >>>>>>> Issue a READ POSITION with the short form specified: > >>>>>>> > >>>>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >>>>>>> > >>>>>>> Issue a READ POSITION with the vendor-specific block numbers: > >>>>>>> > >>>>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > >>>>>>> > >>>>>>> Issue a READ POSITION with the long form data: > >>>>>>> > >>>>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > >>>>>>> > >>>>>>> If it supports the last one, then I can put a quirk (or autodetection) in > >>>>>>> the driver and Bacula will get the hardware filemarks. You should try this > >>>>>>> on your SDLT as well. It may well support it. > >>>>>> > >>>>>> Sadly, no: > >>>>>> > >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd > >>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >>>>>> 00000010 00 00 00 00 |....| > >>>>>> 00000014 > >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd > >>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > >>>>>> 00000010 00 00 00 00 |....| > >>>>>> 00000014 > >>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > >>>>>> camcontrol: error sending command > >>>>>> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00 > >>>>>> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error > >>>>>> (pass2:ahc0:0:2:0): SCSI status: Check Condition > >>>>>> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) > >>>>>> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid > >>>>>> [root@cuppy:~] # > >>>>> > >>>>> Okay. Not too surprising I suppose. > >> > >> > >> Does this mean much to you? > >> > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f > >> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f > >> > >> > >> I'm having trouble with labeling barcodes from Bacula and the above is seen in /var/log/messages > > > > The barcodes issue is resolved. I changed to using drive 0 instead of drive 1, now that we have both drives. > > > > *label barcodes slots=3,4 > > The defined Storage resources are: > > 1: File1 > > 2: OldTL891 > > Select Storage resource (1-2): 2 > > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > > 3306 Issuing autochanger "slots" command. > > Device "DTL03" has 10 slots. > > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > > 3306 Issuing autochanger "list" command. > > The following Volumes will be labeled: > > Slot Volume > > ============== > > 3 FAI261 > > 4 FAI262 > > Do you want to label these Volumes? (yes|no): yes > > Defined Pools: > > 1: Default > > 2: File > > 3: MYDLT > > 4: Scratch > > Select the Pool (1-4): 4 > > Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... > > Sending label command for Volume "FAI261" Slot 3 ... > > 3000 OK label. VolBytes=64512 DVD=0 Volume="FAI261" Device="DTL03" (/dev/nsa0) > > Catalog record for Volume "FAI261", Slot 3 successfully created. > > Sending label command for Volume "FAI262" Slot 4 ... > > 3307 Issuing autochanger "unload slot 3, drive 0" command. > > 3304 Issuing autochanger "load slot 4, drive 0" command. > > 3305 Autochanger "load slot 4, drive 0", status is OK. > > 3000 OK label. VolBytes=64512 DVD=0 Volume="FAI262" Device="DTL03" (/dev/nsa0) > > Catalog record for Volume "FAI262", Slot 4 successfully created. > > *list volumes > > Pool: Default > > No results to list. > > Pool: File > > +---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+ > > | mediaid | volumename | volstatus | enabled | volbytes | volfiles | volretention | recycle | slot | inchanger | mediatype | lastwritten | > > +---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+ > > | 1 | Vol-0001 | Append | 1 | 19,835,982 | 0 | 31,536,000 | 1 | 0 | 0 | File1 | 2015-03-02 17:50:40 | > > | 2 | Vol-0002 | Append | 1 | 0 | 0 | 31,536,000 | 1 | 0 | 0 | DLT | | > > +---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+ > > Pool: MYDLT > > No results to list. > > Pool: Scratch > > +---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+ > > | mediaid | volumename | volstatus | enabled | volbytes | volfiles | volretention | recycle | slot | inchanger | mediatype | lastwritten | > > +---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+ > > | 4 | FAI260 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 1 | 1 | DLT | | > > | 5 | FAI263 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 2 | 1 | DLT | | > > | 7 | FAI261 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 3 | 1 | DLT | | > > | 8 | FAI262 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 4 | 1 | DLT | | > > +---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+ > > * > > > > But this is what arrives in /var/log/messages during the above: > > > > Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f > > Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f > > Mar 2 20:29:06 cuppy kernel: Filtered to period 19, offset f > > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f > > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f > > Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f > > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f > > Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f > > Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f > > Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f > > Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f > > Mar 2 20:30:59 cuppy kernel: Filtered to period 19, offset f > > Mar 2 20:30:59 cuppy kernel: xpt_release_devq(): requested 1 > present 0 > > Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f > > Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f > > Mar 2 20:31:07 cuppy kernel: Filtered to period 19, offset f > > > > Anything to be concerned about? > > When adding a 2nd job to a tape: > > 02-Mar 21:29 cuppy-sd JobId 19: Error: Unable to position to end of data on tape device "DTL03" (/dev/nsa0): ERR=tape_dev.c:345 ioctl MTIOCGET error on "DTL03" (/dev/nsa0). ERR=No error: 0. > > I've gotten this on three consecutive tapes. NOTE: These *are* tapes I no longer use because of higher rates of corrected errors. > > The problem seems to be locating the end of the data. Do you have 'Hardware End of Medium = no' in the configuration file? In looking at the code, it may be set to yes, and that could be the issue here. > > I can run a 4 or 5 jobs in a row, but if I restore a job, then add a job, it fails with the above message. > I would expect that on these particular tape drives because they don't support long position information. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 2 22:03:57 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 00595D48; Mon, 2 Mar 2015 22:03:56 +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 C4630E6D; Mon, 2 Mar 2015 22:03:56 +0000 (UTC) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 7957237F ; Mon, 2 Mar 2015 22:03:54 +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: <20150302214240.GA91133@mithlond.kdm.org> Date: Mon, 2 Mar 2015 17:03:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4FD3E56B-2B55-4C1F-95C2-58366EAD1180@langille.org> References: <20150302003150.GB71528@mithlond.kdm.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@mithlond.kdm.org> <12EED94D-CC9D-44C4-91C2-62C8A51B839B@langille.org> <95BCE742-8CC4-41FC-9FDD-D12C7A337951@langille.org> <20150302214240.GA91133@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: Mon, 02 Mar 2015 22:03:57 -0000 > On Mar 2, 2015, at 4:42 PM, Kenneth D. Merry wrote: >=20 > On Mon, Mar 02, 2015 at 16:34:34 -0500, Dan Langille wrote: >>=20 >>> On Mar 2, 2015, at 2:47 PM, Dan Langille wrote: >>>=20 >>>=20 >>>> On Mar 2, 2015, at 2:07 PM, Dan Langille wrote: >>>>=20 >>>>=20 >>>>> On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry = wrote: >>>>>=20 >>>>> On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote: >>>>>>=20 >>>>>>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry = wrote: >>>>>>>=20 >>>>>>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote: >>>>>>>>=20 >>>>>>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry = wrote: >>>>>>>>>=20 >>>>>>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote: >>>>>>>>>>=20 >>>>>>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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 >>>>>>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf >>>>>>>>>>>>=20 >>>>>>>>>>>> Device { >>>>>>>>>>>> Name =3D DLT >>>>>>>>>>>> Description =3D "QUANTUM DLT7000 1624" >>>>>>>>>>>> Media Type =3D DLT >>>>>>>>>>>> Archive Device =3D /dev/nsa1 >>>>>>>>>>>>=20 >>>>>>>>>>>> Autochanger =3D YES >>>>>>>>>>>> Drive Index =3D 0 >>>>>>>>>>>>=20 >>>>>>>>>>>> Offline On Unmount =3D no >>>>>>>>>>>> Hardware End of Medium =3D yes >>>>>>>>>>>> BSF at EOM =3D yes >>>>>>>>>>>> Backward Space Record =3D no >>>>>>>>>>>> Fast Forward Space File =3D no >>>>>>>>>>>> TWO EOF =3D yes >>>>>>>>>>>> } >>>>>>>>>>>>=20 >>>>>>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from = 2006) has a btape test on this same model. >>>>>>>>>>>>=20 >>>>>>>>>>>> Here's the test I ran tonight: >>>>>>>>>>>>=20 >>>>>>>>>>>> [root@cuppy:/usr/home/dan] # btape -c = /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1 = =20 >>>>>>>>>>>> Tape block granularity is 1024 bytes. >>>>>>>>>>>> btape: butil.c:287-0 Using device: "/dev/nsa1" for writing. >>>>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>>>>> *test >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D >>>>>>>>>>>>=20 >>>>>>>>>>>> I'm going to write 10000 records and an EOF >>>>>>>>>>>> then write 10000 records and an EOF, then rewind, >>>>>>>>>>>> and re-read the data to verify that it is correct. >>>>>>>>>>>>=20 >>>>>>>>>>>> This is an *essential* feature ... >>>>>>>>>>>>=20 >>>>>>>>>>>> btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes. >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1210-0 Rewind OK. >>>>>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>>>>> Got EOF on tape. >>>>>>>>>>>> 10000 blocks re-read correctly. >>>>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read = test =3D=3D=3D >>>>>>>>>>>>=20 >>>>>>>>>>>> btape: btape.c:1277-0 Block position test >>>>>>>>>>>> btape: btape.c:1289-0 Rewind OK. >>>>>>>>>>>> Reposition to file:block 0:4 >>>>>>>>>>>> Block 5 re-read correctly. >>>>>>>>>>>> Reposition to file:block 0:200 >>>>>>>>>>>> Block 201 re-read correctly. >>>>>>>>>>>> Reposition to file:block 0:9999 >>>>>>>>>>>> Block 10000 re-read correctly. >>>>>>>>>>>> Reposition to file:block 1:0 >>>>>>>>>>>> Block 10001 re-read correctly. >>>>>>>>>>>> Reposition to file:block 1:600 >>>>>>>>>>>> Block 10601 re-read correctly. >>>>>>>>>>>> Reposition to file:block 1:9999 >>>>>>>>>>>> Block 20000 re-read correctly. >>>>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read = test =3D=3D=3D >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> =3D=3D=3D Append files test =3D=3D=3D >>>>>>>>>>>>=20 >>>>>>>>>>>> This test is essential to Bacula. >>>>>>>>>>>>=20 >>>>>>>>>>>> I'm going to write one record in file 0, >>>>>>>>>>>> two records in file 1, >>>>>>>>>>>> and three records in file 2 >>>>>>>>>>>>=20 >>>>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:1907-0 Wrote one record of 64412 bytes. >>>>>>>>>>>> btape: btape.c:1909-0 Wrote block to device. >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK >>>>>>>>>>>> btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1) >>>>>>>>>>>> btape: btape.c:1420-0 Now moving to end of medium. >>>>>>>>>>>=20 >>>>>>>>>>> This is the critical piece. The test moves the tape to the = end of the >>>>>>>>>>> medium. With hardware position information, you can tell = what filemark >>>>>>>>>>> you're on. Without it, you can't. >>>>>>>>>>>=20 >>>>>>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on = "DLT" (/dev/nsa1). ERR=3DNo error: 0. >>>>>>>>>>>> We should be in file 3. I am at file 0. This is NOT = correct!!!! >>>>>>>>>>>>=20 >>>>>>>>>>>> Append test failed. Attempting again. >>>>>>>>>>>> Setting "Hardware End of Medium =3D no >>>>>>>>>>>> and "Fast Forward Space File =3D no >>>>>>>>>>>> and retrying append test. >>>>>>>>>>>=20 >>>>>>>>>>> This is not surprsing, given that the drive doesn't support = long read >>>>>>>>>>> position data. (It's a SCSI-2 device.) So that means that = Bacula will >>>>>>>>>>> need to do it manually. >>>>>>>>>>=20 >>>>>>>>>> Yes, I have nothing newer than SCSI-2. Even my SDLT is = SCSI-2 but that >>>>>>>>>> tape library is hooked up to a different computer and was = doing backups today. >>>>>>>>>=20 >>>>>>>>> So, here is one thing that we can try to see whether these = drives support >>>>>>>>> long position information, even though they only claim to be = SCSI-2. If >>>>>>>>> they do, we can potentially add a quirk (or autodetection) to = enable it. >>>>>>>>> The code currently doesn't bother asking drives that claim to = be SCSI-2 >>>>>>>>> for long position information. (Because that feature was = added in the >>>>>>>>> SSC spec, which came after SCSI-2.) >>>>>>>>>=20 >>>>>>>>> Issue a READ POSITION with the short form specified: >>>>>>>>>=20 >>>>>>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>>>>=20 >>>>>>>>> Issue a READ POSITION with the vendor-specific block numbers: >>>>>>>>>=20 >>>>>>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd >>>>>>>>>=20 >>>>>>>>> Issue a READ POSITION with the long form data: >>>>>>>>>=20 >>>>>>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd >>>>>>>>>=20 >>>>>>>>> If it supports the last one, then I can put a quirk (or = autodetection) in >>>>>>>>> the driver and Bacula will get the hardware filemarks. You = should try this >>>>>>>>> on your SDLT as well. It may well support it. >>>>>>>>=20 >>>>>>>> Sadly, no: >>>>>>>>=20 >>>>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 = 0" -i 20 - |hd >>>>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>>>>> 00000010 00 00 00 00 = |....| >>>>>>>> 00000014 >>>>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 = 0" -i 20 - |hd >>>>>>>> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 = |................| >>>>>>>> 00000010 00 00 00 00 = |....| >>>>>>>> 00000014 >>>>>>>> [root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 = 0" -i 32 - |hd >>>>>>>> camcontrol: error sending command >>>>>>>> (pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 = 00 00=20 >>>>>>>> (pass2:ahc0:0:2:0): CAM status: SCSI Status Error >>>>>>>> (pass2:ahc0:0:2:0): SCSI status: Check Condition >>>>>>>> (pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 = (Invalid field in CDB) >>>>>>>> (pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid >>>>>>>> [root@cuppy:~] #=20 >>>>>>>=20 >>>>>>> Okay. Not too surprising I suppose. >>>>=20 >>>>=20 >>>> Does this mean much to you? >>>>=20 >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period = 19, offset f >>>> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period = 19, offset f >>>> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, = offset f >>>> Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period = 19, offset f >>>> Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f >>>>=20 >>>>=20 >>>> I'm having trouble with labeling barcodes from Bacula and the above = is seen in /var/log/messages >>>=20 >>> The barcodes issue is resolved. I changed to using drive 0 instead = of drive 1, now that we have both drives. >>>=20 >>> *label barcodes slots=3D3,4 >>> The defined Storage resources are: >>> 1: File1 >>> 2: OldTL891 >>> Select Storage resource (1-2): 2 >>> Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... >>> 3306 Issuing autochanger "slots" command. >>> Device "DTL03" has 10 slots. >>> Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... >>> 3306 Issuing autochanger "list" command. >>> The following Volumes will be labeled: >>> Slot Volume >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> 3 FAI261 >>> 4 FAI262 >>> Do you want to label these Volumes? (yes|no): yes >>> Defined Pools: >>> 1: Default >>> 2: File >>> 3: MYDLT >>> 4: Scratch >>> Select the Pool (1-4): 4 >>> Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ... >>> Sending label command for Volume "FAI261" Slot 3 ... >>> 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI261" = Device=3D"DTL03" (/dev/nsa0) >>> Catalog record for Volume "FAI261", Slot 3 successfully created. >>> Sending label command for Volume "FAI262" Slot 4 ... >>> 3307 Issuing autochanger "unload slot 3, drive 0" command. >>> 3304 Issuing autochanger "load slot 4, drive 0" command. >>> 3305 Autochanger "load slot 4, drive 0", status is OK. >>> 3000 OK label. VolBytes=3D64512 DVD=3D0 Volume=3D"FAI262" = Device=3D"DTL03" (/dev/nsa0) >>> Catalog record for Volume "FAI262", Slot 4 successfully created. >>> *list volumes >>> Pool: Default >>> No results to list. >>> Pool: File >>> = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= >>> | mediaid | volumename | volstatus | enabled | volbytes | volfiles = | volretention | recycle | slot | inchanger | mediatype | lastwritten = | >>> = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= >>> | 1 | Vol-0001 | Append | 1 | 19,835,982 | 0 = | 31,536,000 | 1 | 0 | 0 | File1 | 2015-03-02 = 17:50:40 | >>> | 2 | Vol-0002 | Append | 1 | 0 | 0 = | 31,536,000 | 1 | 0 | 0 | DLT | = | >>> = +---------+------------+-----------+---------+------------+----------+----= ----------+---------+------+-----------+-----------+---------------------+= >>> Pool: MYDLT >>> No results to list. >>> Pool: Scratch >>> = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ >>> | mediaid | volumename | volstatus | enabled | volbytes | volfiles | = volretention | recycle | slot | inchanger | mediatype | lastwritten | >>> = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ >>> | 4 | FAI260 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 1 | 1 | DLT | | >>> | 5 | FAI263 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 2 | 1 | DLT | | >>> | 7 | FAI261 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 3 | 1 | DLT | | >>> | 8 | FAI262 | Append | 1 | 64,512 | 0 | = 31,536,000 | 1 | 4 | 1 | DLT | | >>> = +---------+------------+-----------+---------+----------+----------+------= --------+---------+------+-----------+-----------+-------------+ >>> * >>>=20 >>> But this is what arrives in /var/log/messages during the above: >>>=20 >>> Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f >>> Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f >>> Mar 2 20:29:06 cuppy kernel: Filtered to period 19, offset f >>> Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f >>> Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f >>> Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f >>> Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f >>> Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f >>> Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f >>> Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f >>> Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f >>> Mar 2 20:30:59 cuppy kernel: Filtered to period 19, offset f >>> Mar 2 20:30:59 cuppy kernel: xpt_release_devq(): requested 1 > = present 0 >>> Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, = offset f >>> Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, = offset f >>> Mar 2 20:31:07 cuppy kernel: Filtered to period 19, offset f >>>=20 >>> Anything to be concerned about? >>=20 >> When adding a 2nd job to a tape: >>=20 >> 02-Mar 21:29 cuppy-sd JobId 19: Error: Unable to position to end of = data on tape device "DTL03" (/dev/nsa0): ERR=3Dtape_dev.c:345 ioctl = MTIOCGET error on "DTL03" (/dev/nsa0). ERR=3DNo error: 0. >>=20 >> I've gotten this on three consecutive tapes. NOTE: These *are* tapes = I no longer use because of higher rates of corrected errors. >>=20 >> The problem seems to be locating the end of the data. >=20 > Do you have 'Hardware End of Medium =3D no' in the configuration = file? >=20 > In looking at the code, it may be set to yes, and that could be the = issue > here. I had it set to yes. Now I'm testing with no and I do not encounter = that error. =20 >> I can run a 4 or 5 jobs in a row, but if I restore a job, then add a = job, it fails with the above message. >>=20 >=20 > I would expect that on these particular tape drives because they don't > support long position information. Ahh, good. =E2=80=94=20 Dan Langille http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 05:49:02 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 8F508808 for ; Tue, 3 Mar 2015 05:49:02 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 5295F14E for ; Tue, 3 Mar 2015 05:49:02 +0000 (UTC) Received: by iecat20 with SMTP id at20so886368iec.6 for ; Mon, 02 Mar 2015 21:49:01 -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=W75AeHM/Mcu+xJDEKbd01V39opSp38ve6omSb74O0p0=; b=TzOmhwOqIBbtPffEJLwFmZduYTme/T9MWnASzW2yFGCPwSEGwxWHGbmr/KOhEoamwE RfyRiQacPVbOAjibUAcZAoNC2n9tbd0rKX/SYkx8VLkVrIBrrMWPKhsi1h3smKmCy/rm HqMr6Gh0ONPL9ka+axOY81W4qsQdAShGoPPjvyOltDSyYwMieYittTln3hPFkP2O1DOJ VNVYKkQ8C3fX/oGsSVH4cwL5tzyUbgBhDZ8cE+GYPhBZS5IiBSprbcckDqhfnfKYhVjE QAUnNdGpG7enhJdP2q727X0U/ZYe2JH/HVYGYNHZdMHu1HeumFBwcI8Jqo5EWR/f0arF vODw== MIME-Version: 1.0 X-Received: by 10.50.143.106 with SMTP id sd10mr27198375igb.17.1425361741743; Mon, 02 Mar 2015 21:49:01 -0800 (PST) Received: by 10.36.23.133 with HTTP; Mon, 2 Mar 2015 21:49:01 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2015 13:49:01 +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: Tue, 03 Mar 2015 05:49:02 -0000 Hi, I added some log. The right information got from device: 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C The wrong information got from device: 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 Compared to the right log, it seems one extra byte *00* is added after every byte. Do you have any idea what can cause the problem? Thanks for your help. Br. Yafeng On Mon, Mar 2, 2015 at 3:49 PM, fengyd wrote: > Hi, > > I found the related code in the function sym_int_sir: > /* > * The device wants us to tranfer more data than > * expected or in the wrong direction. > * The number of extra bytes is in scratcha. > * It is a data overrun condition. > */ > case *SIR_DATA_OVERRUN*: > if (cp) { > OUTONB (HF_PRT, HF_EXT_ERR); > * cp->xerr_status |= XE_EXTRA_DATA;* > cp->extra_bytes += INL (nc_scratcha); > } > goto out; > > I'm not familiar with SCSI. > What does DATA_OVERRUN actually mean? > How can it be triggered? > Could you give more details about it? > > Thanks for your help. > > Br. > Yafeng > > > > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: > >> 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 Tue Mar 3 05:50:08 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 2E03384A for ; Tue, 3 Mar 2015 05:50:08 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 E41E015D for ; Tue, 3 Mar 2015 05:50:07 +0000 (UTC) Received: by iecat20 with SMTP id at20so891471iec.6 for ; Mon, 02 Mar 2015 21:50:07 -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=2n7gmA1Tf+6XTbGGK1kTJboDE6gz71bWdZceHd3GbGk=; b=lka7As1AYHP28QohkayR3CU10TM9BygcGKdPJpe1agC/HGEf6t8NFt98Prc/+JRnbk wCb7k6T8YFmwYAk0qHGUAqcptWm/rLn3zm0GbNNaEVFPwGsQPK4hwUMaeBVopMOWCajh PLbK3a7hBghA3EMolt5zGrw/jkAZ6jr+uz/gX4BpCno0mvOvl6dAzLeT65Rrwd6LmZLm NEEU6te/6kvTudj7gDMgjDFkfFCv820VOkcijjFAb2QNf7vOctHgtz6b9PI9AAF5z81g nUNCelEF2Dh9LlLsutfAlf2nH6PSczwG0k6l3tc3EBE9PRN/WbxR4oCKST0x2+yvVbxR v+VQ== MIME-Version: 1.0 X-Received: by 10.50.93.70 with SMTP id cs6mr25912403igb.6.1425361807454; Mon, 02 Mar 2015 21:50:07 -0800 (PST) Received: by 10.36.23.133 with HTTP; Mon, 2 Mar 2015 21:50:07 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Mar 2015 13:50:07 +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: Tue, 03 Mar 2015 05:50:08 -0000 Hi, I should ask for help from somewhere else? Could someone kindly provide the right email address? Thanks for your help. Br. Yafeng On Tue, Mar 3, 2015 at 1:49 PM, fengyd wrote: > Hi, > > I added some log. > > > > The right information got from device: > > 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 > > 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 > > 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 > > 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C > > > > The wrong information got from device: > > 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 > > 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 > > 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 > > 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 > > > > Compared to the right log, it seems one extra byte *00* is added after > every byte. > > Do you have any idea what can cause the problem? > > > Thanks for your help. > > Br. > Yafeng > > > > On Mon, Mar 2, 2015 at 3:49 PM, fengyd wrote: > >> Hi, >> >> I found the related code in the function sym_int_sir: >> /* >> * The device wants us to tranfer more data than >> * expected or in the wrong direction. >> * The number of extra bytes is in scratcha. >> * It is a data overrun condition. >> */ >> case *SIR_DATA_OVERRUN*: >> if (cp) { >> OUTONB (HF_PRT, HF_EXT_ERR); >> * cp->xerr_status |= XE_EXTRA_DATA;* >> cp->extra_bytes += INL (nc_scratcha); >> } >> goto out; >> >> I'm not familiar with SCSI. >> What does DATA_OVERRUN actually mean? >> How can it be triggered? >> Could you give more details about it? >> >> Thanks for your help. >> >> Br. >> Yafeng >> >> >> >> On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: >> >>> 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 Tue Mar 3 06:51:00 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 C47A4F1D for ; Tue, 3 Mar 2015 06:51:00 +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 7C7D8986 for ; Tue, 3 Mar 2015 06:50:59 +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 t236oqSd098791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Mar 2015 23:50:52 -0700 (MST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.14.9/8.14.9/Submit) id t236oqDV098790; Mon, 2 Mar 2015 23:50:52 -0700 (MST) (envelope-from ken) Date: Mon, 2 Mar 2015 23:50:52 -0700 From: "Kenneth D. Merry" To: fengyd Subject: Re: What does the error code 82 mean? Message-ID: <20150303065052.GA98687@mithlond.kdm.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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]); Mon, 02 Mar 2015 23:50:53 -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: freebsd-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, 03 Mar 2015 06:51:01 -0000 An overrun is exactly what the comment below indicates. It is when the target sends back more data than you asked for. You will generally see it on commands that receive data from a target. How are you sending the INQUIRY command? Are you sending it via the pass(4) driver? How many bytes are you asking for in the CDB? How many bytes are you setting in the dxfer_len field in the CCB? What kind of device are you talking to? Obviously, you're using the sym(4) driver, so I'm guessing this is a parallel SCSI device (unless there is a virtualization stack that emulates the sym(4) hardware). Ken On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: > Hi, > > I found the related code in the function sym_int_sir: > /* > * The device wants us to tranfer more data than > * expected or in the wrong direction. > * The number of extra bytes is in scratcha. > * It is a data overrun condition. > */ > case *SIR_DATA_OVERRUN*: > if (cp) { > OUTONB (HF_PRT, HF_EXT_ERR); > * cp->xerr_status |= XE_EXTRA_DATA;* > cp->extra_bytes += INL (nc_scratcha); > } > goto out; > > I'm not familiar with SCSI. > What does DATA_OVERRUN actually mean? > How can it be triggered? > Could you give more details about it? > > Thanks for your help. > > Br. > Yafeng > > > > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: > > > 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 > >> > > > > > _______________________________________________ > 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" -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 07:50:42 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 BAD636E4; Tue, 3 Mar 2015 07:50:42 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 7A189F0A; Tue, 3 Mar 2015 07:50:42 +0000 (UTC) Received: by iecrd18 with SMTP id rd18so54871460iec.8; Mon, 02 Mar 2015 23:50:41 -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 :cc:content-type; bh=x6UmCA1vgj0hQjauVht4hPZ8SO8H+EiAXs8leNK/sG8=; b=WwdeWz+cVFZJhUJz6lEVMUQiidl2jv1WwbcU+/wRERshh3mhOhcBfehMjG9GRoHUIM L+/38hxHwTOu6Q8RidSPn0/vVSa0RCQ2qK4yD48R5M4tXJoL43fD07dT1IJNR/warDoE 6fuP+KExVhzzAUp09OV7U3RDXS27ArHeaDsTfacjNX8NvDXtBJKx6ks9xLvfPVPsM2e7 lrWjxL/k7I7Y29bPzCU6/Pb76wInVIe+t/WRyLaPc+/CHDR3gkQILrEkfdogZOqb/81Z P/+zje4kQ+V3CrZByv0rROByV+4rGcOqqRzey7dj50VkVNvwmacobs6oco15xmpLev4l iGIw== MIME-Version: 1.0 X-Received: by 10.107.150.149 with SMTP id y143mr150466iod.22.1425369041663; Mon, 02 Mar 2015 23:50:41 -0800 (PST) Received: by 10.36.23.133 with HTTP; Mon, 2 Mar 2015 23:50:41 -0800 (PST) In-Reply-To: <20150303065052.GA98687@mithlond.kdm.org> References: <20150303065052.GA98687@mithlond.kdm.org> Date: Tue, 3 Mar 2015 15:50:41 +0800 Message-ID: Subject: Re: What does the error code 82 mean? From: fengyd To: "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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, 03 Mar 2015 07:50:42 -0000 Hi, Thanks very much for your reply. -How are you sending the INQUIRY command? Yes. -Are you sending it via the pass(4) driver? Yes -How many bytes are you asking for in the CDB? 64 -How many bytes are you setting in the dxfer_len field in the CCB? 64, but it seems the device wants to transfer 128 bytes. -What kind of device are you talking to? Some kernel log: da3 at sym1 bus 0 target 0 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) [image: Inline image 2] The brief connections as above: UNIT0 can access DISK0 and DISK1 by IOC0. UNIT1 can access DISK0 and DISK1 by IOC1. The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, UNIT1 sends INQUIRY to get the basic information from the target, but fails to get the correct information. And I added some log. The right information got from device: 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C The wrong information got from device: 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 Compared to the right log, it seems one extra byte *00* is added after every byte. Thanks for your help. Br. Yafeng On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry wrote: > > An overrun is exactly what the comment below indicates. It is when the > target sends back more data than you asked for. You will generally see it > on commands that receive data from a target. > > How are you sending the INQUIRY command? Are you sending it via the > pass(4) driver? How many bytes are you asking for in the CDB? How many > bytes are you setting in the dxfer_len field in the CCB? > > What kind of device are you talking to? Obviously, you're using the sym(4) > driver, so I'm guessing this is a parallel SCSI device (unless there is a > virtualization stack that emulates the sym(4) hardware). > > Ken > > On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: > > Hi, > > > > I found the related code in the function sym_int_sir: > > /* > > * The device wants us to tranfer more data than > > * expected or in the wrong direction. > > * The number of extra bytes is in scratcha. > > * It is a data overrun condition. > > */ > > case *SIR_DATA_OVERRUN*: > > if (cp) { > > OUTONB (HF_PRT, HF_EXT_ERR); > > * cp->xerr_status |= XE_EXTRA_DATA;* > > cp->extra_bytes += INL (nc_scratcha); > > } > > goto out; > > > > I'm not familiar with SCSI. > > What does DATA_OVERRUN actually mean? > > How can it be triggered? > > Could you give more details about it? > > > > Thanks for your help. > > > > Br. > > Yafeng > > > > > > > > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: > > > > > 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 > > >> > > > > > > > > _______________________________________________ > > 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" > > -- > Kenneth Merry > ken@FreeBSD.ORG > From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 08:11:03 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 D51C610A; Tue, 3 Mar 2015 08:11:03 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 92DF91A8; Tue, 3 Mar 2015 08:11:03 +0000 (UTC) Received: by iebtr6 with SMTP id tr6so55001665ieb.10; Tue, 03 Mar 2015 00:11:03 -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 :cc:content-type; bh=g5up8QA6toF4z9WLk1PslGBKOG1ed+qnzTao04+cIb8=; b=pk8dqc1D3//QYNfHQnccjXsGKXgrHhdZA0+2SU43O0PzBT0qWeJCdWe4FJk07yueUI MniNwWGTpqBmIUSvhdE/0QTu6OjF2ojKTa68EeYQybSDpnmdnH43B2iaChu1ePvn7Chk sF4YtB7mtA2fSogPjzW24tfitmKCcyGNzm/pf/moHNOZ1CF8cMynupalZF7ZAHxHAt2W d394niVMsqH8d1zQXXNmSp6liWnN6MbXHIM1OA3P2b87TtGLYYBPEUMnvUwoomo3fvB2 ovuemhRQKkEQyW5mPf70J7is2jJHyAC5E8KJQ7PBuQHQ708cxDAwZBD4e54vhfFX9dk8 rW9Q== MIME-Version: 1.0 X-Received: by 10.107.40.2 with SMTP id o2mr187203ioo.68.1425370262948; Tue, 03 Mar 2015 00:11:02 -0800 (PST) Received: by 10.36.23.133 with HTTP; Tue, 3 Mar 2015 00:11:02 -0800 (PST) In-Reply-To: References: <20150303065052.GA98687@mithlond.kdm.org> Date: Tue, 3 Mar 2015 16:11:02 +0800 Message-ID: Subject: Re: What does the error code 82 mean? From: fengyd To: "Kenneth D. Merry" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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, 03 Mar 2015 08:11:04 -0000 Hi, I also added some log in the procedure sym_int_sir: case SIR_DATA_OVERRUN: if (cp) { OUTONB (HF_PRT, HF_EXT_ERR); cp->xerr_status |= XE_EXTRA_DATA; cp->extra_bytes += INL (nc_scratcha); xpt_print_path(cp->cam_ccb->ccb_h.path); printf("SIR_DATA_OVERRUN flag = %d, extra_bytes = %d\n", cp->cam_ccb->ccb_h.flags, INL (nc_scratcha)); } goto out; Here's the printout: (pass0:sym0:0:0:0): SIR_DATA_OVERRUN flag = 32832, extra_bytes = 64 (pass0:sym0:0:0:0): COMMAND FAILED (87 0 1). Thanks for your help. Br. Yafeng On Tue, Mar 3, 2015 at 3:50 PM, fengyd wrote: > Hi, > > Thanks very much for your reply. > > -How are you sending the INQUIRY command? > Yes. > -Are you sending it via the pass(4) driver? > Yes > -How many bytes are you asking for in the CDB? > 64 > -How many bytes are you setting in the dxfer_len field in the CCB? > 64, but it seems the device wants to transfer 128 bytes. > > -What kind of device are you talking to? > Some kernel log: > da3 at sym1 bus 0 target 0 lun 0 > da3: Fixed Direct Access SCSI-3 device > da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing > Enabled > da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) > > > [image: Inline image 2] > > The brief connections as above: > UNIT0 can access DISK0 and DISK1 by IOC0. > UNIT1 can access DISK0 and DISK1 by IOC1. > > The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, > UNIT1 sends INQUIRY to get the basic information from the target, but fails > to get the correct information. > > And I added some log. > > > > The right information got from device: > > 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 > > 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 > > 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 > > 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C > > > > The wrong information got from device: > > 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 > > 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 > > 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 > > 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 > > > > Compared to the right log, it seems one extra byte *00* is added after > every byte. > > > > Thanks for your help. > > Br. > Yafeng > > > On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry wrote: > >> >> An overrun is exactly what the comment below indicates. It is when the >> target sends back more data than you asked for. You will generally see it >> on commands that receive data from a target. >> >> How are you sending the INQUIRY command? Are you sending it via the >> pass(4) driver? How many bytes are you asking for in the CDB? How many >> bytes are you setting in the dxfer_len field in the CCB? >> >> What kind of device are you talking to? Obviously, you're using the >> sym(4) >> driver, so I'm guessing this is a parallel SCSI device (unless there is a >> virtualization stack that emulates the sym(4) hardware). >> >> Ken >> >> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: >> > Hi, >> > >> > I found the related code in the function sym_int_sir: >> > /* >> > * The device wants us to tranfer more data than >> > * expected or in the wrong direction. >> > * The number of extra bytes is in scratcha. >> > * It is a data overrun condition. >> > */ >> > case *SIR_DATA_OVERRUN*: >> > if (cp) { >> > OUTONB (HF_PRT, HF_EXT_ERR); >> > * cp->xerr_status |= XE_EXTRA_DATA;* >> > cp->extra_bytes += INL (nc_scratcha); >> > } >> > goto out; >> > >> > I'm not familiar with SCSI. >> > What does DATA_OVERRUN actually mean? >> > How can it be triggered? >> > Could you give more details about it? >> > >> > Thanks for your help. >> > >> > Br. >> > Yafeng >> > >> > >> > >> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: >> > >> > > 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 >> > >> >> > > >> > > >> > _______________________________________________ >> > 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" >> >> -- >> Kenneth Merry >> ken@FreeBSD.ORG >> > > From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 09:15:31 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 3CC14E62 for ; Tue, 3 Mar 2015 09:15:31 +0000 (UTC) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (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 B146AA15 for ; Tue, 3 Mar 2015 09:15:30 +0000 (UTC) Received: by wesw55 with SMTP id w55so38467674wes.4 for ; Tue, 03 Mar 2015 01:15:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=azEZKmZs4PSwDApyppLqkjwbMQl6KoonsKcMaaD8aIw=; b=g1o9rFbwwmqDGG9bRWFo/Vd3rHmt5YV7ZR7vB9xbEd+gDYEHeCrxGWVUsI65pWF5nb OTELu0WGhqZXwOUTLWaec+aVtTeshbVGAkPirEVHMPnuCzk/pv9EajXAQCFBdhRVKOUD Dd9tEKvZdQEzGdYb0IIrUiWizjl7NtGdlVM2TexLrDmx26tTMFHQURdMM/5Bf8fDFDdo AfB/UzGNCMkAVkDKLA/+crcmQviyxteunBPQ7EV45H58MEPzUfm4X7uxN1u5Uk0jPaoK Vn2B+0pKzVj72GCArWSbkhODKUCK/MkZJuQJbpzFE0bBDsRVhmFLhOweisa3nanZWchH clEQ== X-Gm-Message-State: ALoCoQkucImx7a/jFoh9pDd2pHLt86W8kClzCrxxeyhIJNeRzDPScbyUiIX35ZyOz4nRNvdgH/Je MIME-Version: 1.0 X-Received: by 10.194.142.205 with SMTP id ry13mr69172747wjb.73.1425374122979; Tue, 03 Mar 2015 01:15:22 -0800 (PST) Received: by 10.194.37.97 with HTTP; Tue, 3 Mar 2015 01:15:22 -0800 (PST) Date: Tue, 3 Mar 2015 14:45:22 +0530 Message-ID: Subject: iSCSI initiator: iscontrol cannot be stopped or killed From: Aafak Mohammad To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 03 Mar 2015 09:15:31 -0000 Problem: the iscontrol process starts normally and establishes a session and brings up a device, but it cannot be stopped. It does not react to a HUP signal, and neither to KILL. The /dev/da0 device is operational and the remote disk remains normally accessible, regardless of how I try to (unsuccessfully) shutdown the iscontrol process. The ps reports the state of the process as "Ds", not doing anything. A ktrace does not show any reaction to a received signal. A restart seems to be necessary to break the iSCSI session. Using FreeBSD 9.2 info: root@trunk-mar3-node2:~ # ps -aux | grep iscontrol root 3293 0.0 0.1 16340 1884 ?? Ds 2:17PM 0:00.00 iscontrol -c /etc/iscsi.conf -n sbiiscsiDisk31 root 3365 0.0 0.1 16340 1892 ?? Ds 2:20PM 0:00.00 iscontrol -v -c /etc/iscsi.conf -n sbiiscsiDisk32 root@trunk-mar3-node2:~ # root@trunk-mar3-node2:~ # procstat -kka | grep 3293 3293 100659 iscontrol - mi_switch+0x194 sleepq_timedwait+0x42 _sleep+0x1c9 ic_init+0x2e9 i_fullfeature+0x97 iscsi_ioctl+0x66d devfs_ioctl_f+0x7b kern_ioctl+0x106 sys_ioctl+0xfd amd64_syscall+0x5ea Xfast_syscall+0xf7 root@trunk-mar3-node2:~ # procstat -k -k 3293 PID TID COMM TDNAME KSTACK 3293 100659 iscontrol - mi_switch+0x194 sleepq_timedwait+0x42 _sleep+0x1c9 ic_init+0x2e9 i_fullfeature+0x97 iscsi_ioctl+0x66d devfs_ioctl_f+0x7b kern_ioctl+0x106 sys_ioctl+0xfd amd64_syscall+0x5ea Xfast_syscall+0xf7 root@trunk-mar3-node2:~ # procstat -kk grep 3293 procstat: open(grep): No such file or directory procstat: procstat_open() PID TID COMM TDNAME KSTACK 3293 100659 iscontrol - mi_switch+0x194 sleepq_timedwait+0x42 _sleep+0x1c9 ic_init+0x2e9 i_fullfeature+0x97 iscsi_ioctl+0x66d devfs_ioctl_f+0x7b kern_ioctl+0x106 sys_ioctl+0xfd amd64_syscall+0x5ea Xfast_syscall+0xf7 --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 09:20:06 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 4A202EEA for ; Tue, 3 Mar 2015 09:20:06 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (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 CA8B8A51 for ; Tue, 3 Mar 2015 09:20:05 +0000 (UTC) Received: by wesq59 with SMTP id q59so1566847wes.3 for ; Tue, 03 Mar 2015 01:20:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=xovmhGLUZXzD90cKZYZxKIfIyph3Iiof+hulB6M6Gjs=; b=DaYqJd2LHYzvPL7x2IsOCLbsmC4BRkBs4HsGiI3Gnk+R6c3RNEIfGE3a3amH1s+Tew nd3DnoxStpnxuKjd9gYI1kmi6xJjMRLm9YF/k3JqrN09s5hlgqlGY2bX8YEGHm5Bjr5Y a9sEFxoAlQjek2704v+zM7QdYi4fzI8O90PwCCIlCcpAwFx9kXpWHMuq+FXKbZM2dmAy Jd65PLFWRSfYx7hAE3smbbc6V1ZHjFiNSxQZxYPQ8uMDdmk/9pZ4sHf2Mc5frFf5G7HE NZ0OIii54eYcYopgMyNWZgkhFPhLFisRGqwjFii/8v9beHjgbsG1yVLGCd4iDcyV2owM OwpQ== X-Received: by 10.194.11.40 with SMTP id n8mr10416025wjb.43.1425374404241; Tue, 03 Mar 2015 01:20:04 -0800 (PST) Received: from brick.home (adir20.neoplus.adsl.tpnet.pl. [79.184.199.20]) by mx.google.com with ESMTPSA id bd3sm1543357wib.17.2015.03.03.01.20.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 01:20:03 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 3 Mar 2015 09:46:06 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Aafak Mohammad Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed Message-ID: <20150303084606.GA4495@brick.home> Mail-Followup-To: Aafak Mohammad , freebsd-scsi@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-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, 03 Mar 2015 09:20:06 -0000 On 0303T1445, Aafak Mohammad wrote: > Problem: the iscontrol process starts normally and establishes > a session and brings up a device, but it cannot be stopped. > It does not react to a HUP signal, and neither to KILL. > > The /dev/da0 device is operational and the remote disk remains > normally accessible, regardless of how I try to (unsuccessfully) > shutdown the iscontrol process. The ps reports the state of the > process as "Ds", not doing anything. A ktrace does not show any > reaction to a received signal. A restart seems to be necessary > to break the iSCSI session. Well, that's one of the reasons it's obsolete. Could you try to upgrade to 10.1 and try the new iSCSI initiator, iscsictl/iscsid? From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 10:08:27 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 B6CE6F78 for ; Tue, 3 Mar 2015 10:08:27 +0000 (UTC) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 30C9E100 for ; Tue, 3 Mar 2015 10:08:26 +0000 (UTC) Received: by wiwl15 with SMTP id l15so21374020wiw.3 for ; Tue, 03 Mar 2015 02:08:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=OCgViXaHXx9lg1BUwKa8bQ1zWVXmuyUUlSapsru4T1g=; b=TDHcScXeZT7T3SBd/SIz8OUI/2Ej4moEX1Ymw4thRt36xpyp9w425WQ9/OBK7TcDdF 7PyH7nb6VmedcqdC5J410k+IqSO9D4NrdVLcGiVL1Kn5/ycMn+1azGp3sp+aAEPx+j+a seqYaDk9EMFKEcgNwcEcAkUz7kIcSvSiWdhOjDeCKWIbiav7ppkWfaCliF7Z8XBRWoGM z8VF5yiBo3z9XRi5f4DxM/I1Ye4DDTsEeXCEYlhgcPequfM2U58UMW1AKb6uS1XLpGqo KyujiCU0swLbT+DaQ6ryWiRpuZsvoA4MBlLej3omS/RQfCRl60GibXeOLCgnbhCKojKO 7Jmg== X-Gm-Message-State: ALoCoQl+Ly3X7+dAapNbdQ0nzO2plqNJU2tHy8ITmJGZ2Bx+1c18eyW85ZP9B/HbdGin7Ybe/em4 MIME-Version: 1.0 X-Received: by 10.180.149.206 with SMTP id uc14mr44014252wib.57.1425375495666; Tue, 03 Mar 2015 01:38:15 -0800 (PST) Received: by 10.194.37.97 with HTTP; Tue, 3 Mar 2015 01:38:15 -0800 (PST) In-Reply-To: <20150303084606.GA4495@brick.home> References: <20150303084606.GA4495@brick.home> Date: Tue, 3 Mar 2015 15:08:15 +0530 Message-ID: Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed From: Aafak Mohammad To: Aafak Mohammad , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 03 Mar 2015 10:08:27 -0000 Thanks for helping. But for now i cannot upgrade it. Can i get only iscsictl for 9.2? i mean get it from 10.1 and use only this feature in 9.2 will it work ? On Tue, Mar 3, 2015 at 2:16 PM, Edward Tomasz Napiera=C5=82a wrote: > On 0303T1445, Aafak Mohammad wrote: > > Problem: the iscontrol process starts normally and establishes > > a session and brings up a device, but it cannot be stopped. > > It does not react to a HUP signal, and neither to KILL. > > > > The /dev/da0 device is operational and the remote disk remains > > normally accessible, regardless of how I try to (unsuccessfully) > > shutdown the iscontrol process. The ps reports the state of the > > process as "Ds", not doing anything. A ktrace does not show any > > reaction to a received signal. A restart seems to be necessary > > to break the iSCSI session. > > Well, that's one of the reasons it's obsolete. Could you try > to upgrade to 10.1 and try the new iSCSI initiator, iscsictl/iscsid? > > --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 16:28:10 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 465E7E2F for ; Tue, 3 Mar 2015 16:28:10 +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 C68D623A for ; Tue, 3 Mar 2015 16:28:09 +0000 (UTC) Received: from [192.168.6.126] (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t23GS7OC007820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Mar 2015 09:28:08 -0700 (MST) (envelope-from ken@freebsd.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: What does the error code 82 mean? From: Ken Merry In-Reply-To: Date: Tue, 3 Mar 2015 09:28:04 -0700 Message-Id: References: <20150303065052.GA98687@mithlond.kdm.org> To: fengyd X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [70.56.43.85]); Tue, 03 Mar 2015 09:28:08 -0700 (MST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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, 03 Mar 2015 16:28:10 -0000 It sounds like the target reset is causing the drive to reset its = negotiation parameters, and go back to narrow SCSI. UNIT1 still thinks it is talking wide SCSI, but the drive is actually = talking 8 bit. So the drive sends back the 64 bytes of inquiry data in = 64 bus clocks. The drive is only changing the bottom 8 bits, but the = controller thinks it is driving all 16, and records the top 8 bits as = zeros. The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, and = every other byte is zero. So, you=E2=80=99ll need to figure out a way for the sym(4) driver to = figure out that the target has been reset, and re-negotiate with the = drive. You might try seeing what the ahc(4) and ahd(4) drivers do in this = situation. I don=E2=80=99t know whether or not they actually handle it, = but it might be instructive to look. If you have an idea that this may have happened, you can try doing a bus = or target rescan. That may go through the domain validation path and = trigger re-negotiation with the target. Just out of curiosity, why are you doing multi-initiator with this = hardware? It would probably be easier to do all of this with more = modern SAS hardware and expanders. Ken =E2=80=94=20 Ken Merry ken@FreeBSD.ORG > On Mar 3, 2015, at 12:50 AM, fengyd wrote: >=20 > Hi, >=20 > Thanks very much for your reply. >=20 > -How are you sending the INQUIRY command?=20 > Yes. > -Are you sending it via the pass(4) driver? =20 > Yes > -How many bytes are you asking for in the CDB? =20 > 64 > -How many bytes are you setting in the dxfer_len field in the CCB? > 64, but it seems the device wants to transfer 128 bytes. >=20 > -What kind of device are you talking to? =20 > Some kernel log: > da3 at sym1 bus 0 target 0 lun 0 > da3: Fixed Direct Access SCSI-3 device=20 > da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged = Queueing Enabled > da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) >=20 > =20 > >=20 > The brief connections as above: > UNIT0 can access DISK0 and DISK1 by IOC0. > UNIT1 can access DISK0 and DISK1 by IOC1. >=20 > The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, = UNIT1 sends INQUIRY to get the basic information from the target, but = fails to get the correct information. >=20 > And I added some log. > =20 > The right information got from device: >=20 > 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 >=20 > 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 >=20 > 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 >=20 > 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C >=20 > =20 > The wrong information got from device: >=20 > 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 >=20 >=20 > 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 >=20 > 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 >=20 > 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 >=20 > =20 > Compared to the right log, it seems one extra byte 00 is added after = every byte. >=20 >=20 >=20 >=20 > Thanks for your help. >=20 > Br. > Yafeng >=20 >=20 > On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry > wrote: >=20 > An overrun is exactly what the comment below indicates. It is when = the > target sends back more data than you asked for. You will generally = see it > on commands that receive data from a target. >=20 > How are you sending the INQUIRY command? Are you sending it via the > pass(4) driver? How many bytes are you asking for in the CDB? How = many > bytes are you setting in the dxfer_len field in the CCB? >=20 > What kind of device are you talking to? Obviously, you're using the = sym(4) > driver, so I'm guessing this is a parallel SCSI device (unless there = is a > virtualization stack that emulates the sym(4) hardware). >=20 > Ken >=20 > On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: > > Hi, > > > > I found the related code in the function sym_int_sir: > > /* > > * The device wants us to tranfer more data than > > * expected or in the wrong direction. > > * The number of extra bytes is in scratcha. > > * It is a data overrun condition. > > */ > > case *SIR_DATA_OVERRUN*: > > if (cp) { > > OUTONB (HF_PRT, HF_EXT_ERR); > > * cp->xerr_status |=3D XE_EXTRA_DATA;* > > cp->extra_bytes +=3D INL (nc_scratcha); > > } > > goto out; > > > > I'm not familiar with SCSI. > > What does DATA_OVERRUN actually mean? > > How can it be triggered? > > Could you give more details about it? > > > > Thanks for your help. > > > > Br. > > Yafeng > > > > > > > > On Sat, Feb 28, 2015 at 4:50 PM, fengyd > wrote: > > > > > 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 =3D 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 =3D 18 > > >> (pass0:sym0:0:0:0): status =3D 82 > > >> > > >> Do you know what does the error code 82 mean? > > >> > > >> Thanks in advance. > > >> > > >> Br. > > >> Yafeng > > >> > > > > > > > > _______________________________________________ > > 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 = " >=20 > -- > Kenneth Merry > ken@FreeBSD.ORG >=20 From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 3 18:57:24 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 7BEB38C5 for ; Tue, 3 Mar 2015 18:57:24 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 0526E8BF for ; Tue, 3 Mar 2015 18:57:24 +0000 (UTC) Received: by widex7 with SMTP id ex7so23741275wid.1 for ; Tue, 03 Mar 2015 10:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BEqfvz2JdzWAF3YE5jhRjrYBPYl5HQ0j76gx1IBHpp0=; b=NsjwDNfQZt4zaXt02OWmzpOctpPGI1+HXgHgv+KWh2rOjpR0Mz6mmqWxp1vwC7X2m2 xsDffpk/8ecSec1udRbNrZ7cfwgcVJPl6WH6vdOXFD98aGkGUwVba7aeVdWcsB3HYYwR oYcB5sGeOjON3DerDubTAQ2LTNHmNBM60c4EHm5NefF6oqzkhGc9lzCaMEot5m3YMVwJ mRiTNpfz/Kb3wMA6NtGmBF3cq5LPJsK7EKEhEPdbvK41OMFH8y/B+JAiHjvjNnCTZV7e eBaTSNpX4q+0KSufEoilzmj+qH2zWMTQinFH+hXVJ6ZbeAKCsFEnZswqKRq5J/EfBZdu kmxg== X-Received: by 10.194.177.195 with SMTP id cs3mr162866wjc.141.1425409042262; Tue, 03 Mar 2015 10:57:22 -0800 (PST) Received: from brick.home (adir20.neoplus.adsl.tpnet.pl. [79.184.199.20]) by mx.google.com with ESMTPSA id dn1sm211235wid.11.2015.03.03.10.57.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 10:57:21 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Tue, 3 Mar 2015 19:23:23 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Aafak Mohammad Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed Message-ID: <20150303182323.GA5941@brick.home> Mail-Followup-To: Aafak Mohammad , freebsd-scsi@freebsd.org References: <20150303084606.GA4495@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-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, 03 Mar 2015 18:57:24 -0000 I believe the iXsystems has their fork based on 9 with iSCSI backport, but I'm not sure if it includes the client. Their source tree can be found here: https://github.com/trueos/trueos. On 0303T1508, Aafak Mohammad wrote: > Thanks for helping. > But for now i cannot upgrade it. > Can i get only iscsictl for 9.2? > i mean get it from 10.1 and use only this feature in 9.2 > will it work ? > > On Tue, Mar 3, 2015 at 2:16 PM, Edward Tomasz NapieraÅ‚a > wrote: > > > On 0303T1445, Aafak Mohammad wrote: > > > Problem: the iscontrol process starts normally and establishes > > > a session and brings up a device, but it cannot be stopped. > > > It does not react to a HUP signal, and neither to KILL. > > > > > > The /dev/da0 device is operational and the remote disk remains > > > normally accessible, regardless of how I try to (unsuccessfully) > > > shutdown the iscontrol process. The ps reports the state of the > > > process as "Ds", not doing anything. A ktrace does not show any > > > reaction to a received signal. A restart seems to be necessary > > > to break the iSCSI session. > > > > Well, that's one of the reasons it's obsolete. Could you try > > to upgrade to 10.1 and try the new iSCSI initiator, iscsictl/iscsid? From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 4 09:40:51 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 530243BA; Wed, 4 Mar 2015 09:40:51 +0000 (UTC) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 11FDE665; Wed, 4 Mar 2015 09:40:51 +0000 (UTC) Received: by igjz20 with SMTP id z20so35189951igj.4; Wed, 04 Mar 2015 01:40:50 -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 :cc:content-type; bh=5Hjm3dRsZ/kbYT19nnVqXL/J8kEP/L2c+BFsENaFhEg=; b=P3ZmuR8i7JaVeAnwoPSD8mD8/I1HZyYo4VjTz4gg1e4ANDdfbWHtCyY7HCiFaqCNmi Xjzd4EvxXWEvUihNVQiYhy7CNbAY9N0agmWgmbwVFSHIWY79moTJrwhEYTSGl/BOqiHy tK8+ZV33f/sM+zSeftPTi6eG1jVPlLSpHMPZnpSkXW5/VZr1bwPuD26xxVd3zjDql4GS kLLYH7DZ92h1wCRHFhrKNvrgE2Rg5nUT3KmGL/ZglcEeMFMeRevc51PxVigXW1Qklw4L YXfyZocjJwMBQCU7qhc+yfj9j6Ss6XhdEpJuiaWQzCK5o7pTzg97jsHMS6lxJN+KpQid yTPQ== MIME-Version: 1.0 X-Received: by 10.107.17.89 with SMTP id z86mr9580153ioi.52.1425462050358; Wed, 04 Mar 2015 01:40:50 -0800 (PST) Received: by 10.36.23.133 with HTTP; Wed, 4 Mar 2015 01:40:50 -0800 (PST) In-Reply-To: References: <20150303065052.GA98687@mithlond.kdm.org> Date: Wed, 4 Mar 2015 17:40:50 +0800 Message-ID: Subject: Re: What does the error code 82 mean? From: fengyd To: Ken Merry Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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: Wed, 04 Mar 2015 09:40:51 -0000 Hi, It seems that during initialization, data transfer is set as 16-bit by driver, it is set as 8-bit due to target reset. So it means default data transfer for the drive is 8-bit? -You might try seeing what the ahc(4) and ahd(4) drivers do in this situation. I didn't find the code related with ahc or ahd. Do you know in which release ahc and ahd are implemented? -If you have an idea that this may have happened, you can try doing a bus or target rescan. I just begin to study FREEBSD driver. Could you give some instructions how to do bus or target rescan? -Just out of curiosity, why are you doing multi-initiator with this hardware? Two units needs to access the device at the same time. Thanks for your help. Br. Yafeng On Wed, Mar 4, 2015 at 12:28 AM, Ken Merry wrote: > It sounds like the target reset is causing the drive to reset its > negotiation parameters, and go back to narrow SCSI. > > UNIT1 still thinks it is talking wide SCSI, but the drive is actually > talking 8 bit. So the drive sends back the 64 bytes of inquiry data in 6= 4 > bus clocks. The drive is only changing the bottom 8 bits, but the > controller thinks it is driving all 16, and records the top 8 bits as zer= os. > > The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, and = every other byte > is zero. > > So, you=E2=80=99ll need to figure out a way for the sym(4) driver to figu= re out > that the target has been reset, and re-negotiate with the drive. > > You might try seeing what the ahc(4) and ahd(4) drivers do in this > situation. I don=E2=80=99t know whether or not they actually handle it, = but it > might be instructive to look. > > If you have an idea that this may have happened, you can try doing a bus > or target rescan. That may go through the domain validation path and > trigger re-negotiation with the target. > > Just out of curiosity, why are you doing multi-initiator with this > hardware? It would probably be easier to do all of this with more modern > SAS hardware and expanders. > > Ken > =E2=80=94 > Ken Merry > ken@FreeBSD.ORG > > > > On Mar 3, 2015, at 12:50 AM, fengyd wrote: > > Hi, > > Thanks very much for your reply. > > -How are you sending the INQUIRY command? > Yes. > -Are you sending it via the pass(4) driver? > Yes > -How many bytes are you asking for in the CDB? > 64 > -How many bytes are you setting in the dxfer_len field in the CCB? > 64, but it seems the device wants to transfer 128 bytes. > > -What kind of device are you talking to? > Some kernel log: > da3 at sym1 bus 0 target 0 lun 0 > da3: Fixed Direct Access SCSI-3 device > da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing > Enabled > da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) > > > > > The brief connections as above: > UNIT0 can access DISK0 and DISK1 by IOC0. > UNIT1 can access DISK0 and DISK1 by IOC1. > > The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, > UNIT1 sends INQUIRY to get the basic information from the target, but fai= ls > to get the correct information. > > And I added some log. > > > The right information got from device: > > 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 > > 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 > > 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 > > 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C > > > The wrong information got from device: > > 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 > > 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 > > 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 > > 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 > > > Compared to the right log, it seems one extra byte *00* is added after > every byte. > > > > Thanks for your help. > > Br. > Yafeng > > > On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry wrote: > >> >> An overrun is exactly what the comment below indicates. It is when the >> target sends back more data than you asked for. You will generally see = it >> on commands that receive data from a target. >> >> How are you sending the INQUIRY command? Are you sending it via the >> pass(4) driver? How many bytes are you asking for in the CDB? How many >> bytes are you setting in the dxfer_len field in the CCB? >> >> What kind of device are you talking to? Obviously, you're using the >> sym(4) >> driver, so I'm guessing this is a parallel SCSI device (unless there is = a >> virtualization stack that emulates the sym(4) hardware). >> >> Ken >> >> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: >> > Hi, >> > >> > I found the related code in the function sym_int_sir: >> > /* >> > * The device wants us to tranfer more data than >> > * expected or in the wrong direction. >> > * The number of extra bytes is in scratcha. >> > * It is a data overrun condition. >> > */ >> > case *SIR_DATA_OVERRUN*: >> > if (cp) { >> > OUTONB (HF_PRT, HF_EXT_ERR); >> > * cp->xerr_status |=3D XE_EXTRA_DATA;* >> > cp->extra_bytes +=3D INL (nc_scratcha); >> > } >> > goto out; >> > >> > I'm not familiar with SCSI. >> > What does DATA_OVERRUN actually mean? >> > How can it be triggered? >> > Could you give more details about it? >> > >> > Thanks for your help. >> > >> > Br. >> > Yafeng >> > >> > >> > >> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: >> > >> > > 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 =3D 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 returne= d. >> > >> I added some log in the driver: >> > >> SIR_COMPLETE_ERROR >> > >> (pass0:sym0:0:0:0): sym_complete_error status =3D 18 >> > >> (pass0:sym0:0:0:0): status =3D 82 >> > >> >> > >> Do you know what does the error code 82 mean? >> > >> >> > >> Thanks in advance. >> > >> >> > >> Br. >> > >> Yafeng >> > >> >> > > >> > > >> > _______________________________________________ >> > 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= " >> >> -- >> Kenneth Merry >> ken@FreeBSD.ORG >> > > > From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 4 09:44:43 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 7DD6D4D3; Wed, 4 Mar 2015 09:44:43 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (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 3C36F791; Wed, 4 Mar 2015 09:44:43 +0000 (UTC) Received: by igqa13 with SMTP id a13so35179737igq.0; Wed, 04 Mar 2015 01:44:42 -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 :cc:content-type; bh=ADNtKxyKQjsyuCiTkHF4ByCjkl4m6uA9OrxsKhiTS8o=; b=rJng0V+Gk7vXR8+2zXXlNdQzCZhUH4FzNY2dNhBnGLfsk3yGfvbaHFQuzNcDHJTpVQ vAOUYQU8hYLZZSkedPNjcg2jLc/HkxS9PVqL39vcjtpJuQQRlsFFtn8jWhvOpHsXUxJl GD7cny0CWhnM8D+oBuWCXwusmdtMDQz4aI0d001TEshMs2JCawFAao7IjZ4l5YiILOaY 9lfWHKmMbjam8Fj+SemcITd7/giscgbcyyD9bVc6Tb41C/Fp0cTuUZLbvGO7Rgf/JiNU B9GjJnk5x50MClU3I5jb1yThbJFoEvpXtV4MhZSDJZu2ToKw9kkQMj8jIF9TMcMJpXLK 4IrA== MIME-Version: 1.0 X-Received: by 10.107.17.89 with SMTP id z86mr9602772ioi.52.1425462282492; Wed, 04 Mar 2015 01:44:42 -0800 (PST) Received: by 10.36.23.133 with HTTP; Wed, 4 Mar 2015 01:44:42 -0800 (PST) In-Reply-To: References: <20150303065052.GA98687@mithlond.kdm.org> Date: Wed, 4 Mar 2015 17:44:42 +0800 Message-ID: Subject: Re: What does the error code 82 mean? From: fengyd To: Ken Merry Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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: Wed, 04 Mar 2015 09:44:43 -0000 Hi, The code to reset the target: static void sym_reset_dev(hcb_p np, union ccb *ccb) { tcb_p tp; struct ccb_hdr *ccb_h =3D &ccb->ccb_h; if (ccb_h->target_id =3D=3D np->myaddr || ccb_h->target_id >=3D SYM_CONF_MAX_TARGET || ccb_h->target_lun >=3D SYM_CONF_MAX_LUN) { sym_xpt_done2(np, ccb, CAM_DEV_NOT_THERE); return; } tp =3D &np->target[ccb_h->target_id]; tp->to_reset =3D 1; sym_xpt_done2(np, ccb, CAM_REQ_CMP); np->istat_sem =3D SEM; OUTB (nc_istat, SIGP|SEM); return; } Can target reset set data transfer with the size provided by driver? Thanks for your help. Br. Yafeng On Wed, Mar 4, 2015 at 5:40 PM, fengyd wrote: > Hi, > > It seems that during initialization, data transfer is set as 16-bit by > driver, it is set as 8-bit due to target reset. > So it means default data transfer for the drive is 8-bit? > > -You might try seeing what the ahc(4) and ahd(4) drivers do in this > situation. > I didn't find the code related with ahc or ahd. > Do you know in which release ahc and ahd are implemented? > > -If you have an idea that this may have happened, you can try doing a bus > or target rescan. > I just begin to study FREEBSD driver. > Could you give some instructions how to do bus or target rescan? > > -Just out of curiosity, why are you doing multi-initiator with this > hardware? > Two units needs to access the device at the same time. > > Thanks for your help. > > Br. > Yafeng > > On Wed, Mar 4, 2015 at 12:28 AM, Ken Merry wrote: > >> It sounds like the target reset is causing the drive to reset its >> negotiation parameters, and go back to narrow SCSI. >> >> UNIT1 still thinks it is talking wide SCSI, but the drive is actually >> talking 8 bit. So the drive sends back the 64 bytes of inquiry data in = 64 >> bus clocks. The drive is only changing the bottom 8 bits, but the >> controller thinks it is driving all 16, and records the top 8 bits as ze= ros. >> >> The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, and= every other byte >> is zero. >> >> So, you=E2=80=99ll need to figure out a way for the sym(4) driver to fig= ure out >> that the target has been reset, and re-negotiate with the drive. >> >> You might try seeing what the ahc(4) and ahd(4) drivers do in this >> situation. I don=E2=80=99t know whether or not they actually handle it,= but it >> might be instructive to look. >> >> If you have an idea that this may have happened, you can try doing a bus >> or target rescan. That may go through the domain validation path and >> trigger re-negotiation with the target. >> >> Just out of curiosity, why are you doing multi-initiator with this >> hardware? It would probably be easier to do all of this with more moder= n >> SAS hardware and expanders. >> >> Ken >> =E2=80=94 >> Ken Merry >> ken@FreeBSD.ORG >> >> >> >> On Mar 3, 2015, at 12:50 AM, fengyd wrote: >> >> Hi, >> >> Thanks very much for your reply. >> >> -How are you sending the INQUIRY command? >> Yes. >> -Are you sending it via the pass(4) driver? >> Yes >> -How many bytes are you asking for in the CDB? >> 64 >> -How many bytes are you setting in the dxfer_len field in the CCB? >> 64, but it seems the device wants to transfer 128 bytes. >> >> -What kind of device are you talking to? >> Some kernel log: >> da3 at sym1 bus 0 target 0 lun 0 >> da3: Fixed Direct Access SCSI-3 device >> da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing >> Enabled >> da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) >> >> >> >> >> The brief connections as above: >> UNIT0 can access DISK0 and DISK1 by IOC0. >> UNIT1 can access DISK0 and DISK1 by IOC1. >> >> The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, >> UNIT1 sends INQUIRY to get the basic information from the target, but fa= ils >> to get the correct information. >> >> And I added some log. >> >> >> The right information got from device: >> >> 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 >> >> 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 >> >> 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 >> >> 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C >> >> >> The wrong information got from device: >> >> 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 >> >> 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 >> >> 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 >> >> 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 >> >> >> Compared to the right log, it seems one extra byte *00* is added after >> every byte. >> >> >> >> Thanks for your help. >> >> Br. >> Yafeng >> >> >> On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry wrote= : >> >>> >>> An overrun is exactly what the comment below indicates. It is when the >>> target sends back more data than you asked for. You will generally see >>> it >>> on commands that receive data from a target. >>> >>> How are you sending the INQUIRY command? Are you sending it via the >>> pass(4) driver? How many bytes are you asking for in the CDB? How man= y >>> bytes are you setting in the dxfer_len field in the CCB? >>> >>> What kind of device are you talking to? Obviously, you're using the >>> sym(4) >>> driver, so I'm guessing this is a parallel SCSI device (unless there is= a >>> virtualization stack that emulates the sym(4) hardware). >>> >>> Ken >>> >>> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: >>> > Hi, >>> > >>> > I found the related code in the function sym_int_sir: >>> > /* >>> > * The device wants us to tranfer more data than >>> > * expected or in the wrong direction. >>> > * The number of extra bytes is in scratcha. >>> > * It is a data overrun condition. >>> > */ >>> > case *SIR_DATA_OVERRUN*: >>> > if (cp) { >>> > OUTONB (HF_PRT, HF_EXT_ERR); >>> > * cp->xerr_status |=3D XE_EXTRA_DATA;* >>> > cp->extra_bytes +=3D INL (nc_scratcha); >>> > } >>> > goto out; >>> > >>> > I'm not familiar with SCSI. >>> > What does DATA_OVERRUN actually mean? >>> > How can it be triggered? >>> > Could you give more details about it? >>> > >>> > Thanks for your help. >>> > >>> > Br. >>> > Yafeng >>> > >>> > >>> > >>> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd wrote: >>> > >>> > > 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 =3D 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 =3D 18 >>> > >> (pass0:sym0:0:0:0): status =3D 82 >>> > >> >>> > >> Do you know what does the error code 82 mean? >>> > >> >>> > >> Thanks in advance. >>> > >> >>> > >> Br. >>> > >> Yafeng >>> > >> >>> > > >>> > > >>> > _______________________________________________ >>> > freebsd-scsi@freebsd.org mailing list >>> > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >>> > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.or= g >>> " >>> >>> -- >>> Kenneth Merry >>> ken@FreeBSD.ORG >>> >> >> >> > From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 4 16:20:50 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 406A8F29 for ; Wed, 4 Mar 2015 16:20:50 +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 AE4E4AA1 for ; Wed, 4 Mar 2015 16:20:49 +0000 (UTC) Received: from [10.0.0.101] ([10.0.0.101]) (authenticated bits=0) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t24GKgc7027706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2015 09:20:42 -0700 (MST) (envelope-from ken@freebsd.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: What does the error code 82 mean? From: Ken Merry In-Reply-To: Date: Wed, 4 Mar 2015 09:20:42 -0700 Message-Id: References: <20150303065052.GA98687@mithlond.kdm.org> To: fengyd X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [70.56.43.85]); Wed, 04 Mar 2015 09:20:42 -0700 (MST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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: Wed, 04 Mar 2015 16:20:50 -0000 By default, SCSI starts out at 8 bits wide, with async (3.3MB/sec) = transfers. The target and initiator have to negotiate up from there. Look in sys/dev/aic7xxx for the ahc(4) and ahd(4) drivers. To do a bus or a target rescan, you can do: camcontrol rescan 0 camcontrol rescan 0:0 See dorescan_or_reset() in sbin/camcontrol/camcontrol.c Is it always an INQUIRY that is sent from UNIT1 after you reset the = target from UNIT0? Or is that just where you see problems? If you send a TEST UNIT READY instead, you should get a Unit Attention = condition back from the target, and you=E2=80=99ll know that you need to = re-negotiate. You can also request different negotiation parameters = with =E2=80=98camcontrol negotiate=E2=80=99. But that depends on driver = support to some extent. A rescan should in theory trigger = re-negotiation if need be. If you=E2=80=99re doing a HA appliance, you will generally need a = communication channel between the nodes apart from SCSI. If you=E2=80=99r= e going to reset a disk from one node, you can tell the other node you = did that, and it can do a rescan or re-negotiate. Ken =E2=80=94=20 Ken Merry ken@FreeBSD.ORG > On Mar 4, 2015, at 2:40 AM, fengyd wrote: >=20 > Hi, >=20 > It seems that during initialization, data transfer is set as 16-bit by = driver, it is set as 8-bit due to target reset. > So it means default data transfer for the drive is 8-bit? >=20 > -You might try seeing what the ahc(4) and ahd(4) drivers do in this = situation. > I didn't find the code related with ahc or ahd. > Do you know in which release ahc and ahd are implemented? >=20 > -If you have an idea that this may have happened, you can try doing a = bus or target rescan. > I just begin to study FREEBSD driver. > Could you give some instructions how to do bus or target rescan? >=20 > -Just out of curiosity, why are you doing multi-initiator with this = hardware? =20 > Two units needs to access the device at the same time. >=20 > Thanks for your help. >=20 > Br. > Yafeng >=20 > On Wed, Mar 4, 2015 at 12:28 AM, Ken Merry > wrote: > It sounds like the target reset is causing the drive to reset its = negotiation parameters, and go back to narrow SCSI. >=20 > UNIT1 still thinks it is talking wide SCSI, but the drive is actually = talking 8 bit. So the drive sends back the 64 bytes of inquiry data in = 64 bus clocks. The drive is only changing the bottom 8 bits, but the = controller thinks it is driving all 16, and records the top 8 bits as = zeros. >=20 > The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, = and every other byte is zero. >=20 > So, you=E2=80=99ll need to figure out a way for the sym(4) driver to = figure out that the target has been reset, and re-negotiate with the = drive. >=20 > You might try seeing what the ahc(4) and ahd(4) drivers do in this = situation. I don=E2=80=99t know whether or not they actually handle it, = but it might be instructive to look. >=20 > If you have an idea that this may have happened, you can try doing a = bus or target rescan. That may go through the domain validation path = and trigger re-negotiation with the target. >=20 > Just out of curiosity, why are you doing multi-initiator with this = hardware? It would probably be easier to do all of this with more = modern SAS hardware and expanders. >=20 > Ken > =E2=80=94=20 > Ken Merry > ken@FreeBSD.ORG >=20 >=20 >=20 >> On Mar 3, 2015, at 12:50 AM, fengyd > wrote: >>=20 >> Hi, >>=20 >> Thanks very much for your reply. >>=20 >> -How are you sending the INQUIRY command?=20 >> Yes. >> -Are you sending it via the pass(4) driver? =20 >> Yes >> -How many bytes are you asking for in the CDB? =20 >> 64 >> -How many bytes are you setting in the dxfer_len field in the CCB? >> 64, but it seems the device wants to transfer 128 bytes. >>=20 >> -What kind of device are you talking to? =20 >> Some kernel log: >> da3 at sym1 bus 0 target 0 lun 0 >> da3: Fixed Direct Access SCSI-3 device=20 >> da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged = Queueing Enabled >> da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) >>=20 >> =20 >> >>=20 >> The brief connections as above: >> UNIT0 can access DISK0 and DISK1 by IOC0. >> UNIT1 can access DISK0 and DISK1 by IOC1. >>=20 >> The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, = UNIT1 sends INQUIRY to get the basic information from the target, but = fails to get the correct information. >>=20 >> And I added some log. >> =20 >> The right information got from device: >>=20 >> 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 >>=20 >> 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 >>=20 >> 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 >>=20 >> 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C >>=20 >> =20 >> The wrong information got from device: >>=20 >> 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 >>=20 >>=20 >> 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 >>=20 >> 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 >>=20 >> 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 >>=20 >> =20 >> Compared to the right log, it seems one extra byte 00 is added after = every byte. >>=20 >>=20 >>=20 >>=20 >> Thanks for your help. >>=20 >> Br. >> Yafeng >>=20 >>=20 >> On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry > wrote: >>=20 >> An overrun is exactly what the comment below indicates. It is when = the >> target sends back more data than you asked for. You will generally = see it >> on commands that receive data from a target. >>=20 >> How are you sending the INQUIRY command? Are you sending it via the >> pass(4) driver? How many bytes are you asking for in the CDB? How = many >> bytes are you setting in the dxfer_len field in the CCB? >>=20 >> What kind of device are you talking to? Obviously, you're using the = sym(4) >> driver, so I'm guessing this is a parallel SCSI device (unless there = is a >> virtualization stack that emulates the sym(4) hardware). >>=20 >> Ken >>=20 >> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: >> > Hi, >> > >> > I found the related code in the function sym_int_sir: >> > /* >> > * The device wants us to tranfer more data than >> > * expected or in the wrong direction. >> > * The number of extra bytes is in scratcha. >> > * It is a data overrun condition. >> > */ >> > case *SIR_DATA_OVERRUN*: >> > if (cp) { >> > OUTONB (HF_PRT, HF_EXT_ERR); >> > * cp->xerr_status |=3D XE_EXTRA_DATA;* >> > cp->extra_bytes +=3D INL (nc_scratcha); >> > } >> > goto out; >> > >> > I'm not familiar with SCSI. >> > What does DATA_OVERRUN actually mean? >> > How can it be triggered? >> > Could you give more details about it? >> > >> > Thanks for your help. >> > >> > Br. >> > Yafeng >> > >> > >> > >> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd > wrote: >> > >> > > 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 =3D 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 =3D 18 >> > >> (pass0:sym0:0:0:0): status =3D 82 >> > >> >> > >> Do you know what does the error code 82 mean? >> > >> >> > >> Thanks in advance. >> > >> >> > >> Br. >> > >> Yafeng >> > >> >> > > >> > > >> > _______________________________________________ >> > 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 = " >>=20 >> -- >> Kenneth Merry >> ken@FreeBSD.ORG >>=20 >=20 >=20 From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 4 16:24:17 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 6061154F for ; Wed, 4 Mar 2015 16:24:17 +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 E1E98BE1 for ; Wed, 4 Mar 2015 16:24:16 +0000 (UTC) Received: from [10.0.0.101] ([10.0.0.101]) (authenticated bits=0) by mithlond.kdm.org (8.14.9/8.14.9) with ESMTP id t24GOFs3027785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2015 09:24:16 -0700 (MST) (envelope-from ken@freebsd.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: What does the error code 82 mean? From: Ken Merry In-Reply-To: Date: Wed, 4 Mar 2015 09:24:15 -0700 Message-Id: <8689E5CD-4E89-48D1-B0EE-3821E7174A0D@freebsd.org> References: <20150303065052.GA98687@mithlond.kdm.org> To: fengyd X-Mailer: Apple Mail (2.2070.6) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [70.56.43.85]); Wed, 04 Mar 2015 09:24:16 -0700 (MST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-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: Wed, 04 Mar 2015 16:24:17 -0000 The challenge is that the data transfer rate is reset on the target for = both the initiator doing the reset, and the other initiator. So re-negotiating from the initiator that did the reset will do no good. = You need to re-negotiate from the other initiator. You can either detect the situation from a unit attention (that you will = get in response from a test unit ready) returned from the target, or you = can communicate between the nodes so that the other node knows that it = needs to re-negotiate. Ken =E2=80=94=20 Ken Merry ken@FreeBSD.ORG > On Mar 4, 2015, at 2:44 AM, fengyd wrote: >=20 > Hi, >=20 > The code to reset the target: > static void sym_reset_dev(hcb_p np, union ccb *ccb) > { > tcb_p tp; > struct ccb_hdr *ccb_h =3D &ccb->ccb_h; >=20 > if (ccb_h->target_id =3D=3D np->myaddr || > ccb_h->target_id >=3D SYM_CONF_MAX_TARGET || > ccb_h->target_lun >=3D SYM_CONF_MAX_LUN) { > sym_xpt_done2(np, ccb, CAM_DEV_NOT_THERE); > return; > } >=20 > tp =3D &np->target[ccb_h->target_id]; >=20 > tp->to_reset =3D 1; > sym_xpt_done2(np, ccb, CAM_REQ_CMP); >=20 > np->istat_sem =3D SEM; > OUTB (nc_istat, SIGP|SEM); > return; > } >=20 > Can target reset set data transfer with the size provided by driver? >=20 >=20 > Thanks for your help. >=20 > Br. > Yafeng >=20 > On Wed, Mar 4, 2015 at 5:40 PM, fengyd > wrote: > Hi, >=20 > It seems that during initialization, data transfer is set as 16-bit by = driver, it is set as 8-bit due to target reset. > So it means default data transfer for the drive is 8-bit? >=20 > -You might try seeing what the ahc(4) and ahd(4) drivers do in this = situation. > I didn't find the code related with ahc or ahd. > Do you know in which release ahc and ahd are implemented? >=20 > -If you have an idea that this may have happened, you can try doing a = bus or target rescan. > I just begin to study FREEBSD driver. > Could you give some instructions how to do bus or target rescan? >=20 > -Just out of curiosity, why are you doing multi-initiator with this = hardware? =20 > Two units needs to access the device at the same time. >=20 > Thanks for your help. >=20 > Br. > Yafeng >=20 > On Wed, Mar 4, 2015 at 12:28 AM, Ken Merry > wrote: > It sounds like the target reset is causing the drive to reset its = negotiation parameters, and go back to narrow SCSI. >=20 > UNIT1 still thinks it is talking wide SCSI, but the drive is actually = talking 8 bit. So the drive sends back the 64 bytes of inquiry data in = 64 bus clocks. The drive is only changing the bottom 8 bits, but the = controller thinks it is driving all 16, and records the top 8 bits as = zeros. >=20 > The result is that you get 64 bytes of =E2=80=9Cextra=E2=80=9D data, = and every other byte is zero. >=20 > So, you=E2=80=99ll need to figure out a way for the sym(4) driver to = figure out that the target has been reset, and re-negotiate with the = drive. >=20 > You might try seeing what the ahc(4) and ahd(4) drivers do in this = situation. I don=E2=80=99t know whether or not they actually handle it, = but it might be instructive to look. >=20 > If you have an idea that this may have happened, you can try doing a = bus or target rescan. That may go through the domain validation path = and trigger re-negotiation with the target. >=20 > Just out of curiosity, why are you doing multi-initiator with this = hardware? It would probably be easier to do all of this with more = modern SAS hardware and expanders. >=20 > Ken > =E2=80=94=20 > Ken Merry > ken@FreeBSD.ORG >=20 >=20 >=20 >> On Mar 3, 2015, at 12:50 AM, fengyd > wrote: >>=20 >> Hi, >>=20 >> Thanks very much for your reply. >>=20 >> -How are you sending the INQUIRY command?=20 >> Yes. >> -Are you sending it via the pass(4) driver? =20 >> Yes >> -How many bytes are you asking for in the CDB? =20 >> 64 >> -How many bytes are you setting in the dxfer_len field in the CCB? >> 64, but it seems the device wants to transfer 128 bytes. >>=20 >> -What kind of device are you talking to? =20 >> Some kernel log: >> da3 at sym1 bus 0 target 0 lun 0 >> da3: Fixed Direct Access SCSI-3 device=20 >> da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged = Queueing Enabled >> da3: 70136MB (143638992 512 byte sectors: 255H 63S/T 8941C) >>=20 >> =20 >> >>=20 >> The brief connections as above: >> UNIT0 can access DISK0 and DISK1 by IOC0. >> UNIT1 can access DISK0 and DISK1 by IOC1. >>=20 >> The problem happens when UNIT0 sends XPT_RESET_DEV to reset one disk, = UNIT1 sends INQUIRY to get the basic information from the target, but = fails to get the correct information. >>=20 >> And I added some log. >> =20 >> The right information got from device: >>=20 >> 00 00 03 12 5B 00 01 3A 46 55 4A 49 54 53 55 20 >>=20 >> 4D 42 41 33 30 37 33 4E 50 20 20 20 20 20 20 20 >>=20 >> 34 37 30 32 42 42 53 32 50 41 41 30 31 31 46 34 >>=20 >> 00 00 00 00 00 00 00 00 0F 00 00 40 0B 54 01 3C >>=20 >> =20 >> The wrong information got from device: >>=20 >> 00 00 00 00 03 00 12 00 5B 00 00 00 01 00 3A 00 >>=20 >>=20 >> 46 00 55 00 4A 00 49 00 54 00 53 00 55 00 20 00 >>=20 >> 4D 00 42 00 41 00 33 00 30 00 37 00 33 00 4E 00 >>=20 >> 50 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 >>=20 >> =20 >> Compared to the right log, it seems one extra byte 00 is added after = every byte. >>=20 >>=20 >>=20 >>=20 >> Thanks for your help. >>=20 >> Br. >> Yafeng >>=20 >>=20 >> On Tue, Mar 3, 2015 at 2:50 PM, Kenneth D. Merry > wrote: >>=20 >> An overrun is exactly what the comment below indicates. It is when = the >> target sends back more data than you asked for. You will generally = see it >> on commands that receive data from a target. >>=20 >> How are you sending the INQUIRY command? Are you sending it via the >> pass(4) driver? How many bytes are you asking for in the CDB? How = many >> bytes are you setting in the dxfer_len field in the CCB? >>=20 >> What kind of device are you talking to? Obviously, you're using the = sym(4) >> driver, so I'm guessing this is a parallel SCSI device (unless there = is a >> virtualization stack that emulates the sym(4) hardware). >>=20 >> Ken >>=20 >> On Mon, Mar 02, 2015 at 15:49:57 +0800, fengyd wrote: >> > Hi, >> > >> > I found the related code in the function sym_int_sir: >> > /* >> > * The device wants us to tranfer more data than >> > * expected or in the wrong direction. >> > * The number of extra bytes is in scratcha. >> > * It is a data overrun condition. >> > */ >> > case *SIR_DATA_OVERRUN*: >> > if (cp) { >> > OUTONB (HF_PRT, HF_EXT_ERR); >> > * cp->xerr_status |=3D XE_EXTRA_DATA;* >> > cp->extra_bytes +=3D INL (nc_scratcha); >> > } >> > goto out; >> > >> > I'm not familiar with SCSI. >> > What does DATA_OVERRUN actually mean? >> > How can it be triggered? >> > Could you give more details about it? >> > >> > Thanks for your help. >> > >> > Br. >> > Yafeng >> > >> > >> > >> > On Sat, Feb 28, 2015 at 4:50 PM, fengyd > wrote: >> > >> > > 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 =3D 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 =3D 18 >> > >> (pass0:sym0:0:0:0): status =3D 82 >> > >> >> > >> Do you know what does the error code 82 mean? >> > >> >> > >> Thanks in advance. >> > >> >> > >> Br. >> > >> Yafeng >> > >> >> > > >> > > >> > _______________________________________________ >> > 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 = " >>=20 >> -- >> Kenneth Merry >> ken@FreeBSD.ORG >>=20 >=20 >=20 >=20 From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 5 04:53:03 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 8A532CA7 for ; Thu, 5 Mar 2015 04:53:03 +0000 (UTC) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 F0C90A17 for ; Thu, 5 Mar 2015 04:53:02 +0000 (UTC) Received: by wibbs8 with SMTP id bs8so4158906wib.4 for ; Wed, 04 Mar 2015 20:52:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=HajTllqLzRZ/pdaEWSYNJokmEQTfjB0QPSKddycQ5xc=; b=i+aHTEAKFEwVf+oyEcQ9QRDgsf2Y4DI26vyWOjBMvsQxPGv/S+rPn4dtFLTRAzc/KH r42m6aqyTue2CazpffEN7FX9u5Q4KG8bnYLmeOZ8605aMd0TjhstgqGKGL1FCKJ6OpfU Wt+zKq3xzCixZ01jY9n5stJRf1ouBhWd3QOTDkcQv6QRaTakxJ+nEokuj9SHOInnzK2L sp715Fp61KJttH84+E1GrwEyZiKmE6myN0Q2ipSLu0f3lVFbVZ8jDTqFJnHzO39PNc4k IZqrgTlmjS3wHOLPp/Bm/yfoQqdk0hFxdxX39XbXxFnoMJXQ2//lLy9H0EinMTSxpuvh tBKw== X-Gm-Message-State: ALoCoQmOC6K/7M0b189h3O00KZTuiDcBPqC18RVnLAibHFVJ6qqQvj2rUjQW48PPi0bUcNVZmS20 MIME-Version: 1.0 X-Received: by 10.180.149.206 with SMTP id uc14mr61810451wib.57.1425531175573; Wed, 04 Mar 2015 20:52:55 -0800 (PST) Received: by 10.194.37.97 with HTTP; Wed, 4 Mar 2015 20:52:55 -0800 (PST) In-Reply-To: <20150303182323.GA5941@brick.home> References: <20150303084606.GA4495@brick.home> <20150303182323.GA5941@brick.home> Date: Thu, 5 Mar 2015 10:22:55 +0530 Message-ID: Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed From: Aafak Mohammad To: Aafak Mohammad , freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 05 Mar 2015 04:53:03 -0000 >From where i can get latest and stable iscsicitl/iscsid source code? On Tue, Mar 3, 2015 at 11:53 PM, Edward Tomasz Napiera=C5=82a wrote: > I believe the iXsystems has their fork based on 9 with iSCSI backport, > but I'm not sure if it includes the client. Their source tree can be > found here: https://github.com/trueos/trueos. > > On 0303T1508, Aafak Mohammad wrote: > > Thanks for helping. > > But for now i cannot upgrade it. > > Can i get only iscsictl for 9.2? > > i mean get it from 10.1 and use only this feature in 9.2 > > will it work ? > > > > On Tue, Mar 3, 2015 at 2:16 PM, Edward Tomasz Napiera=C5=82a < > trasz@freebsd.org> > > wrote: > > > > > On 0303T1445, Aafak Mohammad wrote: > > > > Problem: the iscontrol process starts normally and establishes > > > > a session and brings up a device, but it cannot be stopped. > > > > It does not react to a HUP signal, and neither to KILL. > > > > > > > > The /dev/da0 device is operational and the remote disk remains > > > > normally accessible, regardless of how I try to (unsuccessfully) > > > > shutdown the iscontrol process. The ps reports the state of the > > > > process as "Ds", not doing anything. A ktrace does not show any > > > > reaction to a received signal. A restart seems to be necessary > > > > to break the iSCSI session. > > > > > > Well, that's one of the reasons it's obsolete. Could you try > > > to upgrade to 10.1 and try the new iSCSI initiator, iscsictl/iscsid? > --=20 Thanks and Regards, Aafak [image: cid:image001.png@01CF7E5A.8A69F530] Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, 27th Main, Sector =E2=80=93 1, HSR Layout, Bangalore =E2=80=93 560102, Call: (91)-80-2258-2804 www.cloudbyte.com From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 5 13:28: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 2B89BCD8 for ; Thu, 5 Mar 2015 13:28:14 +0000 (UTC) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (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 A738D796 for ; Thu, 5 Mar 2015 13:28:13 +0000 (UTC) Received: by wgha1 with SMTP id a1so2667814wgh.1 for ; Thu, 05 Mar 2015 05:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=WQBVuUsKnW0ZVtShlsJ5MaGbVErC4Ts1p+T08rFGx2g=; b=zxo8DsoLxxYOYd7WGkHH8eIYfmXD155VaJZYjhzdcyMD3nrji0EBdfeMmrunRYVMFN KPzzGfLfBc4q4yh8iYOCm7gy1FGpYbWLMULsCylARZhSSlnErKGWL4YWxT6Aitp6GDAt whmiivd5AixhmlXAmsjMS4F3buRQyDSCcMoFVtXQUqo7KeDA6Y+FCnfFndHJkSq8eqiW rJJRAoKTJ7QjIq+URQhFOJSytc/yTcwrtwcL0kUW6xnWF4TqVMep5g3iC1EFAUZ7nnuN N3hGZGJFkMbkL06c92/vuoPrM5hsy1mREBlq4sYG9hNiKjYF8MhBWZmdJIxiA2mIqFP/ 5p3Q== X-Received: by 10.194.2.43 with SMTP id 11mr18842332wjr.104.1425562092055; Thu, 05 Mar 2015 05:28:12 -0800 (PST) Received: from brick.home (dgo34.neoplus.adsl.tpnet.pl. [83.23.170.34]) by mx.google.com with ESMTPSA id y3sm10535680wju.14.2015.03.05.05.28.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 05:28:10 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 5 Mar 2015 13:54:13 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Aafak Mohammad Subject: Re: iSCSI initiator: iscontrol cannot be stopped or killed Message-ID: <20150305125413.GH10733@brick.home> Mail-Followup-To: Aafak Mohammad , freebsd-scsi@freebsd.org References: <20150303084606.GA4495@brick.home> <20150303182323.GA5941@brick.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-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, 05 Mar 2015 13:28:14 -0000 It's not just iscsictl and iscsid you need; the main part of the initiator lives in the kernel. And to build it, you need to put it in the right places in the FreeBSD source tree. Anyhow: they are at usr.bin/iscsictl/ and usr.sbin/iscsid/, relative to the source tree root. Latest and greatest is always in 11-CURRENT. On 0305T1022, Aafak Mohammad wrote: > From where i can get latest and stable iscsicitl/iscsid source code? > > On Tue, Mar 3, 2015 at 11:53 PM, Edward Tomasz NapieraÅ‚a > wrote: > > > I believe the iXsystems has their fork based on 9 with iSCSI backport, > > but I'm not sure if it includes the client. Their source tree can be > > found here: https://github.com/trueos/trueos. > > > > On 0303T1508, Aafak Mohammad wrote: > > > Thanks for helping. > > > But for now i cannot upgrade it. > > > Can i get only iscsictl for 9.2? > > > i mean get it from 10.1 and use only this feature in 9.2 > > > will it work ? > > > > > > On Tue, Mar 3, 2015 at 2:16 PM, Edward Tomasz NapieraÅ‚a < > > trasz@freebsd.org> > > > wrote: > > > > > > > On 0303T1445, Aafak Mohammad wrote: > > > > > Problem: the iscontrol process starts normally and establishes > > > > > a session and brings up a device, but it cannot be stopped. > > > > > It does not react to a HUP signal, and neither to KILL. > > > > > > > > > > The /dev/da0 device is operational and the remote disk remains > > > > > normally accessible, regardless of how I try to (unsuccessfully) > > > > > shutdown the iscontrol process. The ps reports the state of the > > > > > process as "Ds", not doing anything. A ktrace does not show any > > > > > reaction to a received signal. A restart seems to be necessary > > > > > to break the iSCSI session. > > > > > > > > Well, that's one of the reasons it's obsolete. Could you try > > > > to upgrade to 10.1 and try the new iSCSI initiator, iscsictl/iscsid? > > > > > > -- > Thanks and Regards, > Aafak > [image: cid:image001.png@01CF7E5A.8A69F530] > > Plot No. : 2799 & 2800, Srinidhi Bldg, 3rd Floor, > 27th Main, Sector – 1, HSR Layout, > Bangalore – 560102, Call: (91)-80-2258-2804 > www.cloudbyte.com > _______________________________________________ > 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" From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 5 15:00:45 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 ADAED70B for ; Thu, 5 Mar 2015 15:00:45 +0000 (UTC) Received: from sc31-mx-03.schema31.it (2-228-74-186.ip190.fastwebnet.it [2.228.74.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.schema31.it", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48125348 for ; Thu, 5 Mar 2015 15:00:44 +0000 (UTC) Received: from stmp.schema31.it ([10.33.102.167]) by sc31-mx-03.schema31.it (8.14.9/8.14.9) with ESMTP id t25F0Xx7093357 for ; Thu, 5 Mar 2015 16:00:34 +0100 (CET) (envelope-from abrancatelli@schema31.it) Message-ID: <54F86F91.80603@schema31.it> Date: Thu, 05 Mar 2015 16:00:33 +0100 From: Andrea Brancatelli Organization: Schema31 S.p.a. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: New iSCSI initiator with Dell TL2000 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (sc31-mx-03.schema31.it [10.33.102.167]); Thu, 05 Mar 2015 16:00:34 +0100 (CET) X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00, HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on rubidio.roma.schema31.it Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 05 Mar 2015 15:00:45 -0000 Hello everybody. We have a marvelous Dell Powervault TL2000 here, with the iSCSI bridge. Our "backup server", with Bacula running on it, used to be a 9.1 machine and used to work ok :-) Today we upgraded to FreeBSD 10 and tried to switch to new iscsid, but we weren't able to connect to the iSCSI device. This is what we found in the TL2000 log file: Mar 5 14:51:15 (UTC) bwcore[216]: iSCSI: Connection accepted from 10.40.3.1 Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: New session from iqn.1994-09.org.freebsd:arsenico.roma.schema31.it to iqn.1988-11.com.dell.20278e:eui.5000e111456c2002.0 Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: request to login to target iqn.1988-11.com.dell.20278e:eui.5000e111456c2002.0 Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: Login request with illegal stage Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: Local socket closure Mar 5 14:52:45 (UTC) bwcore[216]: iSCSI: Connection accepted from 10.40.3.1 The session is an un-authenticated CHAP. The problem seems to be with the "Login request with illegal stage". As of now we switched back to iscontrol and everything is ok. -- *Andrea Brancatelli Schema31 S.p.A. Responsabile IT* BO - FI - ROMA - PA ITALY Tel: +39.06.98358472 Cell: +39.331.2488468 Fax: +39.055.71880466 Società del gruppo SC31 ITALIA From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 5 17:42:42 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 BB97D185 for ; Thu, 5 Mar 2015 17:42:42 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (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 5F9B4D09 for ; Thu, 5 Mar 2015 17:42:42 +0000 (UTC) Received: by wesx3 with SMTP id x3so7864870wes.4 for ; Thu, 05 Mar 2015 09:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=+nT697xX5eyOWSaSN/xtsZixFLSAPuZmaBOM3y0Pmk8=; b=OL4YLjWrUgnmMVU2pAi5btpBpkFR5R0j9bM8ntiiS8fl9UCHNahtTRttMJAWJgqdw6 42OmXSJ8WRm1eTeeOg9O7OPRSUtrJtkoXs4sW5mX9Zfu0hRcETI0FDCJL9QICCjRZXAt mXBLcn+5rMMZDCkMu/Sdk6yG/G+jIloCg6qgNt+sPrz6DlcHRK3AiByfL/QioTFwtKBR ysZM/i4Sk/Cs7lzfv420ky6c8hOmZH92RiJaJpO7g/pNlRzfaEzTRC8fvnDDAB8sDheA J3+GUmUR7Z+AUDsSyJiDXoLI/FtJem4nAGZAlvqz91TgoDVKUBJ7yza4K/xL2uiLH8+2 kqtA== X-Received: by 10.180.83.102 with SMTP id p6mr45999372wiy.78.1425577360612; Thu, 05 Mar 2015 09:42:40 -0800 (PST) Received: from brick.home (dgo34.neoplus.adsl.tpnet.pl. [83.23.170.34]) by mx.google.com with ESMTPSA id v5sm9392689wiw.24.2015.03.05.09.42.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 09:42:39 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 5 Mar 2015 18:08:42 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Andrea Brancatelli Subject: Re: New iSCSI initiator with Dell TL2000 Message-ID: <20150305170842.GA12103@brick.home> Mail-Followup-To: Andrea Brancatelli , freebsd-scsi@freebsd.org References: <54F86F91.80603@schema31.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F86F91.80603@schema31.it> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-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, 05 Mar 2015 17:42:42 -0000 On 0305T1600, Andrea Brancatelli wrote: > Hello everybody. > > We have a marvelous Dell Powervault TL2000 here, with the iSCSI bridge. > > Our "backup server", with Bacula running on it, used to be a 9.1 machine > and used to work ok :-) > > Today we upgraded to FreeBSD 10 and tried to switch to new iscsid, but FreeBSD 10.what exactly? 10.1? > we weren't able to connect to the iSCSI device. > > This is what we found in the TL2000 log file: > > > Mar 5 14:51:15 (UTC) bwcore[216]: iSCSI: Connection accepted from 10.40.3.1 > Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: New session from > iqn.1994-09.org.freebsd:arsenico.roma.schema31.it to > iqn.1988-11.com.dell.20278e:eui.5000e111456c2002.0 > Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: request to login to target > iqn.1988-11.com.dell.20278e:eui.5000e111456c2002.0 > Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: Login request with illegal stage > Mar 5 14:51:15 (UTC) bwcore[238]: iSCSI: Local socket closure > Mar 5 14:52:45 (UTC) bwcore[216]: iSCSI: Connection accepted from 10.40.3.1 Could you do this: kill iscsid (pkill iscsid), then start iscsid like this: while :; do iscsid -d; done ... then, with this running in a terminal, try to add the session, then copy/paste the output and mail me? Thanks! From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 7 13:30:39 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 18033D2A; Sat, 7 Mar 2015 13:30:39 +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 7A8B7D13; Sat, 7 Mar 2015 13:30:38 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id t27DUY6g041576; Sat, 7 Mar 2015 14:30:34 +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 AE9739B; Sat, 7 Mar 2015 14:30:33 +0100 (CET) Message-ID: <54FAFD72.4080704@omnilan.de> Date: Sat, 07 Mar 2015 14:30:26 +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="------------enig8E6262DF2F82D76D7986ED99" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sat, 07 Mar 2015 14:30:34 +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: Sat, 07 Mar 2015 13:30:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E6262DF2F82D76D7986ED99 Content-Type: text/plain; charset=ISO-8859-1 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 Hello, on 26/02/2105, r278964 seems to be part from the sa_changes patchset. Do you have a sa_changes.stable_10.20150226 ready? Or is it just a matter of exluding all parts, comitted with r278964=20 from the patchset? I've done so in the mean while: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/sa_changes.stable_10.201502= 26.fudge.patch Noticed that in sys/dev/mps/mps_sas.c 'cdai.flags' gets conditionally (#if __FreeBSD_version >=3D 1100061) the new "CDAI_FLAG_NONE", while in sbin/camcontrol/camcontrol.c, this is unconditionally used. Haven't really looked at the code, mostly because my skills wouldN#t allow me to answer this qusteion myself, but is that versioncheck in mps_sas.c still vaild with the rest of the sa_driver-changes? Thanks, -Harry --------------enig8E6262DF2F82D76D7986ED99 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) iEYEARECAAYFAlT6/XgACgkQLDqVQ9VXb8hYdQCgqeV5CmoPFyz60K3Nio7gVXSM 0boAn0U8uT2dR93gN3i0KVwqVAtD1+Np =8H3a -----END PGP SIGNATURE----- --------------enig8E6262DF2F82D76D7986ED99--