> On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry <k...@freebsd.org> 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 <k...@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 <k...@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@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.
Ahh: Trying to mount root from zfs:system/bootenv/FreeBSDHEad []... sa0 at ahc0 bus 0 scbus0 target 1 lun 0 sa0: <DEC TZ89 (C) DEC 2561> 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 > >>> >>> 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 >>>>> k...@freebsd.org >>>>> _______________________________________________ >>>>> freebsd-s...@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >>>>> To unsubscribe, send any mail to "freebsd-scsi-unsubscr...@freebsd.org" >>>> >>>> ? >>>> Dan Langille >>>> http://langille.org/ >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Kenneth Merry >>> k...@freebsd.org >> >> ? >> Dan Langille >> http://langille.org/ >> >> >> >> >> > > Ken > -- > Kenneth Merry > k...@freebsd.org — Dan Langille http://langille.org/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
