sa(4) driver changes available for test
Kenneth D. Merry
ken at FreeBSD.ORG
Mon Mar 2 00:37:03 UTC 2015
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.ORG
More information about the freebsd-scsi
mailing list