Re: sa(4) driver changes available for test

From: Dan Langille <dan_at_langille.org>
Date: Mon, 24 Aug 2015 17:24:22 -0400
> On Mar 2, 2015, at 12:26 PM, Kenneth D. Merry <ken_at_freebsd.org> wrote:
> 
> On Mon, Mar 02, 2015 at 11:43:15 -0500, Dan Langille wrote:
>> 
>>> On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry <ken_at_FreeBSD.ORG> wrote:
>>> 
>>> On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote:
>>>> 
>>>>> On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry <ken_at_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 <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.
>>>> 
>>>> 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

Ken,

FYI, I upgraded a 9.3 server to 10.2 yesterday. A message similar to the above is seen here:

(sa0:sym0:0:1:0): 64512-byte tape record bigger than supplied buffer

Is this just informational?  If so, I'll ignore it.

>>> 
>>> Okay.  Well, no indication of what happened.  Perhaps boot -v will show it,
>>> perhaps not.
>>> 
>> 
>> Good news.  After a reboot, both tape drives are present:
>> 
>> $ ls -l /dev/*sa*
>> crw-rw----  1 root  operator  0x61 Mar  2 17:27 /dev/esa0
>> crw-rw----  1 root  operator  0x65 Mar  2 17:27 /dev/esa1
>> crw-rw----  1 root  operator  0x60 Mar  2 17:27 /dev/nsa0
>> crw-rw----  1 root  operator  0x64 Mar  2 17:27 /dev/nsa1
>> crw-rw----  1 root  operator  0x5f Mar  2 17:27 /dev/sa0
>> crw-rw----  1 root  operator  0x5e Mar  2 17:27 /dev/sa0.ctl
>> crw-rw----  1 root  operator  0x63 Mar  2 17:27 /dev/sa1
>> crw-rw----  1 root  operator  0x62 Mar  2 17:27 /dev/sa1.ctl
>> 
> 
> Ahh, good.  Glad it is working now!
> 
> Ken
> -- 
> Kenneth Merry
> ken_at_FreeBSD.ORG

— 
Dan Langille
http://langille.org/
Received on Mon Aug 24 2015 - 19:24:25 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC