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/