Date: Mon, 24 Aug 2015 17:24:22 -0400 From: Dan Langille <dan@langille.org> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: scsi@freebsd.org, current@freebsd.org Subject: Re: sa(4) driver changes available for test Message-ID: <E29289EB-FE63-4CAC-B534-395A1DCC972B@langille.org> In-Reply-To: <20150302172629.GA87055@mithlond.kdm.org> References: <20150214003232.GA63990@mithlond.kdm.org> <4A478C5C-7965-498E-9F0F-80192265E310@langille.org> <20150302001833.GA71528@mithlond.kdm.org> <6C82281F-649A-4DA8-8ACF-17E81C04F730@langille.org> <20150302003658.GA72258@mithlond.kdm.org> <DF7D6419-C120-4162-8391-ACB9DD921A50@langille.org> <20150302020608.GA73433@mithlond.kdm.org> <30C55F00-2DE4-4596-96EA-2E3CC40B4DB6@langille.org> <20150302172629.GA87055@mithlond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Mar 2, 2015, at 12:26 PM, Kenneth D. Merry <ken@freebsd.org> wrote: >=20 > On Mon, Mar 02, 2015 at 11:43:15 -0500, Dan Langille wrote: >>=20 >>> On Mar 1, 2015, at 9:06 PM, Kenneth D. Merry <ken@FreeBSD.ORG> = wrote: >>>=20 >>> On Sun, Mar 01, 2015 at 19:40:40 -0500, Dan Langille wrote: >>>>=20 >>>>> On Mar 1, 2015, at 7:36 PM, Kenneth D. Merry <ken@FreeBSD.ORG> = wrote: >>>>>=20 >>>>> On Sun, Mar 01, 2015 at 19:28:37 -0500, Dan Langille wrote: >>>>>>=20 >>>>>>> On Mar 1, 2015, at 7:18 PM, Kenneth D. Merry <ken@FreeBSD.ORG> = wrote: >>>>>>>=20 >>>>>>> On Sun, Mar 01, 2015 at 17:06:24 -0500, Dan Langille wrote: >>>>>>>>=20 >>>>>>>>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry = <ken@freebsd.org> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> A description of the changes is here and below in this = message. >>>>>>>>>=20 >>>>>>>>> If you have tape hardware and the inclination, I'd appreciate = testing and >>>>>>>>> feedback. >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> Rough draft commit message: >>>>>>>>>=20 >>>>>>>>> = http://people.freebsd.org/~ken/sa_changes_commitmsg.20150213.3.txt >>>>>>>>>=20 >>>>>>>>> The patches against FreeBSD/head as of SVN revision 278706: >>>>>>>>>=20 >>>>>>>>> http://people.freebsd.org/~ken/sa_changes.20150213.3.txt >>>>>>>>>=20 >>>>>>>>> And (untested) patches against FreeBSD stable/10 as of SVN = revision 278721. >>>>>>>>>=20 >>>>>>>>> = http://people.freebsd.org/~ken/sa_changes.stable_10.20150213.3.txt >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>>=20 >>>>>>>>> The intent is to get the tape infrastructure more up to date, = so we can >>>>>>>>> support LTFS and more modern tape drives: >>>>>>>>>=20 >>>>>>>>> http://www.ibm.com/systems/storage/tape/ltfs/ >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> The commit message below outlines most of the changes. >>>>>>>>>=20 >>>>>>>>> A few comments: >>>>>>>>>=20 >>>>>>>>> 1. I'm planning to commit the XPT_DEV_ADVINFO changes = separately. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 3. I have tested with a reasonable amount of tape hardware = (see below for a >>>>>>>>> list), but more testing and feedback would be good. >>>>>>>>>=20 >>>>>>>>> 4. Standard 'mt status' output looks like this: >>>>>>>>>=20 >>>>>>>>> # 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 >>>>>>>>>=20 >>>>>>>>> 5. 'mt status -v' looks like this: >>>>>>>>>=20 >>>>>>>>> # 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> # 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=3DFAI260 = =20 >>>>>>>> Storage Element 5:Full :VolumeTag=3DFAI261 = =20 >>>>>>>> Storage Element 6:Full :VolumeTag=3DFAI262 = =20 >>>>>>>> Storage Element 7:Full :VolumeTag=3DFAI263 = =20 >>>>>>>> Storage Element 8:Empty >>>>>>>> Storage Element 9:Empty >>>>>>>> Storage Element 10:Empty >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> It was at this point I spent the next 90 minute trying to get = the tape=20 >>>>>>>> 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. :/ >>>>>>>=20 >>>>>>> Thanks for all of the effort! Looks like it is paying off! :) >>>>>>>=20 >>>>>>>> When I do this command, I hear the drive move a bit, to read = the tape: >>>>>>>>=20 >>>>>>>> # 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 >>>>>>>=20 >>>>>>> Looks like the drive isn't reporting position information. It = will still >>>>>>> be useful to try it with Bacula, though. >>>>>>>=20 >>>>>>>> # mt -f /dev/nsa1 ostatus =20 >>>>>>>> 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 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> After doing a very small tar -c and tar -x, I have: >>>>>>>>=20 >>>>>>>> # 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 >>>>>>>=20 >>>>>>> Woohoo! It works. >>>>>>>=20 >>>>>>>> # 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 >>>>>>>>=20 >>>>>>>> I may not get to testing Bacula today. =20 >>>>>>>>=20 >>>>>>>> Based on the above, is there any commands you'd like me to try? >>>>>>>=20 >>>>>>> Aside from making sure things work okay with Bacula, that is = probably >>>>>>> sufficient. These drives won't support density reports or = position >>>>>>> information. >>>>>>>=20 >>>>>>>> Read below regarding two tape drives >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 6. Existing applications should work without changes. If not, = please let >>>>>>>>> me know. Hopefully they will move over time to the new = interfaces. >>>>>>>>>=20 >>>>>>>>> 7. There are lots of additional features that could be added = later. >>>>>>>>> Append-only support, encryption, more log pages, etc. >>>>>>>>>=20 >>>>>>>>> 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=20 >>>>>>>>> to the status XML from the sa(4) driver. >>>>>>>>>=20 >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> Significant upgrades to sa(4) and mt(1). >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> Significant changes and new features include: >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> o The extra sa(4) /dev entries (/dev/saN.[0-3]) have been = removed. >>>>>>>>=20 >>>>>>>> How does this affect a tape library with more than one tape = drive? >>>>>>>>=20 >>>>>>>> [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) >>>>>>>>=20 >>>>>>>> This system has two tapes drives and I can access them through = the front panel but: >>>>>>>>=20 >>>>>>>> # 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 >>>>>>>>=20 >>>>>>>> ... only one tape drives shows up. >>>>>>>=20 >>>>>>>=20 >>>>>>> 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'? >>>>>>=20 >>>>>> # 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) >>>>>>=20 >>>>>>=20 >>>>>> BUT! >>>>>>=20 >>>>>> # grep sa /var/run/dmesg.boot=20 >>>>>> 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=20 >>>>>> sa0: Serial Number CXA22S2338 >>>>>> sa0: 10.000MB/s transfers (10.000MHz, offset 15) >>>>>> sa0: quirks=3D0x100<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=20 >>>>>> sa1: Serial Number CXA09S1340 >>>>>> sa1: 10.000MB/s transfers (10.000MHz, offset 15) >>>>>> sa1: quirks=3D0x100<NO_LONG_POS> >>>>>=20 >>>>> 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. >>>>=20 >>>> Ahh: >>>>=20 >>>> 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. >>>=20 >>> Okay. Well, no indication of what happened. Perhaps boot -v will = show it, >>> perhaps not. >>>=20 >>=20 >> Good news. After a reboot, both tape drives are present: >>=20 >> $ 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 >>=20 >=20 > Ahh, good. Glad it is working now! >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG =E2=80=94=20 Dan Langille http://langille.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E29289EB-FE63-4CAC-B534-395A1DCC972B>