On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: > > > On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry <ken_at_FreeBSD.ORG> 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 <ken_at_freebsd.org> 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: <IBM ULTRIUM-HH6 E4J1> 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: <IBM ULTRIUM-HH6 E4J1> 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: <DEC TZ89 (C) DEC 2561> 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: <DEC TZ89 (C) DEC 2561> 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_at_cuppy:~] # camcontrol amcontrol devlist > >> <DEC TL800 (C) DEC 0525> at scbus0 target 0 lun 0 (pass0,ch0) > >> <DEC TZ89 (C) DEC 2561> at scbus0 target 2 lun 0 (sa1,pass2) > >> <WDC WD5000AAKS-00YGA0 12.01C02> at scbus1 target 0 lun 0 (pass3,ada0) > >> <WDC WD5000AAKS-00YGA0 12.01C02> at scbus2 target 0 lun 0 (pass4,ada1) > >> <AHCI SGPIO Enclosure 1.00 0001> 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: > <DEC TL800 (C) DEC 0525> at scbus0 target 0 lun 0 (pass0,ch0) > <DEC TZ89 (C) DEC 2561> at scbus0 target 2 lun 0 (sa1,pass2) > <> at scbus0 target -1 lun ffffffff () > scbus1 on ahcich2 bus 0: > <WDC WD5000AAKS-00YGA0 12.01C02> at scbus1 target 0 lun 0 (pass3,ada0) > <> at scbus1 target -1 lun ffffffff () > scbus2 on ahcich4 bus 0: > <WDC WD5000AAKS-00YGA0 12.01C02> at scbus2 target 0 lun 0 (pass4,ada1) > <> at scbus2 target -1 lun ffffffff () > scbus3 on ahciem0 bus 0: > <AHCI SGPIO Enclosure 1.00 0001> 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: <PCI-ISA bridge> at device 31.0 on pci0 > isa0: <ISA bus> on isab0 > orm0: <ISA Option ROM> at iomem 0xce800-0xcefff on isa0 > atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0 > sa0 at ahc0 bus 0 scbus0 target 1 lun 0 > sa0: <DEC TZ89 (C) DEC 2561> Removable Sequential Access SCSI-2 device > sa0: Serial Number CXA22S2338 > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > sa0: quirks=0x100<NO_LONG_POS> > sa1 at ahc0 bus 0 scbus0 target 2 lun 0 > sa1: <DEC TZ89 (C) DEC 2561> Removable Sequential Access SCSI-2 device > sa1: Serial Number CXA09S1340 > sa1: 10.000MB/s transfers (10.000MHz, offset 15) > sa1: quirks=0x100<NO_LONG_POS> 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_at_FreeBSD.ORG > >>> _______________________________________________ > >>> freebsd-scsi_at_freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > >>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe_at_freebsd.org" > >> > >> ? > >> Dan Langille > >> http://langille.org/ > >> > >> > >> > >> > >> > > > > -- > > Kenneth Merry > > ken_at_FreeBSD.ORG > > ? > Dan Langille > http://langille.org/ > > > > > Ken -- Kenneth Merry ken_at_FreeBSD.ORGReceived on Sun Mar 01 2015 - 23:37:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC