sa(4) driver changes available for test
Dan Langille
dan at langille.org
Mon Mar 2 16:43:18 UTC 2015
> 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
>
> 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
—
Dan Langille
http://langille.org/
More information about the freebsd-scsi
mailing list