sa(4) driver changes available for test

[Kenneth D. Merry]

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

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.

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
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
To unsubscribe, send any mail to "freebsd-scsi...@freebsd.org"

[Dan Langille]

> 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.

I have a DLT 8000 and an SDLT 220.

I don't have anything running current, but I have a spare machine which I could use for testing.

Do you see any value is tests with that hardware? I'd be testing it via Bacula.

disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.

I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

On Sat, Feb 14, 2015 at 18:22:43 -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.
>
> I have a DLT 8000 and an SDLT 220.
>
> I don't have anything running current, but I have a spare machine which I could use for testing.
>
> Do you see any value is tests with that hardware? I'd be testing it via Bacula.
>
> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
>

Actually, yes. Bacula is a bit tricky to configure, so your trying it out
would be helpful if you have the time.

In looking at the manuals for both the SDLT 220 and the DLT 8000, they both
claim to support long position information for the SCSI READ POSITION
command.

You can see what I'm talking about by doing:

mt eod
mt status

On my DDS-4 tape drive, this shows:

# mt -f /dev/nsa3 status

Drive: sa3: <SEAGATE DAT 06240-XXX 8071> Serial Number: HJ00YWY

---------------------------------
Mode Density Blocksize bpi Compression

Current: 0x26:DDS-4 1024 bytes 97000 enabled (DCLZ)

---------------------------------
Current Driver State: at rest.
---------------------------------

Partition: 0 Calc File Number: -1 Calc Record Number: -1
Residual: 0 Reported File Number: -1 Reported Record Number: -1
Flags: None

But on an LTO-5, which will give long position information, I get:

[root@doc ~]# mt status
Drive: sa0: <IBM ULTRIUM-HH5 E4J1>

---------------------------------
Mode Density Blocksize bpi Compression

Current: 0x58:LTO-5 variable 384607 enabled (0x1)

---------------------------------
Current Driver State: at rest.
---------------------------------

Partition: 0 Calc File Number: 2 Calc Record Number: -1
Residual: 0 Reported File Number: 2 Reported Record Number: 32373
Flags: None

That, in combination with the changes I made to the position information
code in the driver, mean that even the old MTIOCGET ioctl should return an
accurate file number at end of data. e.g., on the LTO-5:

[root@doc ~]# mt ostatus

Mode Density Blocksize bpi Compression

Current: 0x58:LTO-5 variable 384607 0x1
---------available modes---------
0: 0x58:LTO-5 variable 384607 0x1
1: 0x58:LTO-5 variable 384607 0x1
2: 0x58:LTO-5 variable 384607 0x1
3: 0x58:LTO-5 variable 384607 0x1

---------------------------------
Current Driver State: at rest.
---------------------------------

File Number: 2 Record Number: -1 Residual Count -1

So the thing to try, in addition to just making sure that Bacula continues
to work properly, is to try setting this for the tape drive in
bacula-sd.conf:

Hardware End of Medium = yes

It looks like the Bacula tape program (btape) has a test mode, and it would
be good to run through the tests on one of the tape drives and see whether
they work, and whether the results are different before and after the
changes. I'm not sure how to enable the test mode.

> I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL.
>

Thanks! If there are additional features they would like out of the tape
driver, I'm happy to talk about it. (Or help if they'd like to use the new
status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.)

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Kenneth D. Merry]

I have updated the patches.

I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
I committed those separately.

I have (hopefully) fixed the build for the stable/10 patches by MFCing
dependencies. (One of them mav did for me, thanks!)

Rough draft commit message:

http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt

The patches against FreeBSD/head as of SVN revision 278975:

http://people.freebsd.org/~ken/sa_changes.20150218.1.txt

And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:

http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

Thanks,

Ken

[Harald Schmalzbauer]

Bezüglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime):

> I have updated the patches.
>
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
>
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies. (One of them mav did for me, thanks!)
>
> Rough draft commit message:
>
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>
> The patches against FreeBSD/head as of SVN revision 278975:
>
> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
>
> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>
> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

Ken,

thank you very much for your work!
Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly
appreciate your work on tape support for FreeBSD!
I compiled your 10-stable patchset for one machine with LTO2 and DDS5
drives, but haven't done much testing since I'll replace the adaptec
(39160) because it's maxio is limited to 64k (while 53c1020 has 128k).
sa(4) seems to work just fine with both drives, mt(1) showing "Reported
File/Record Number" :-) No EOM tests done so far…

I'll archive zfs streams, therefore I needed some kind of forward error
correction. Probably people following this thread also have found to
need this, therefore I'd like to point to the new port misc/vdmfec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950
Perhaps someone want's to take this bug report.

Thanks,

-Harry

[Kenneth D. Merry]

On Thu, Feb 26, 2015 at 10:57:50 +0100, Harald Schmalzbauer wrote:
> Bez?glich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime):

> > I have updated the patches.
> >
> > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> > I committed those separately.
> >
> > I have (hopefully) fixed the build for the stable/10 patches by MFCing
> > dependencies. (One of them mav did for me, thanks!)
> >
> > Rough draft commit message:
> >
> > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
> >
> > The patches against FreeBSD/head as of SVN revision 278975:
> >
> > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
> >
> > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
> >
> > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt
>
> Ken,
>
> thank you very much for your work!
> Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly
> appreciate your work on tape support for FreeBSD!
> I compiled your 10-stable patchset for one machine with LTO2 and DDS5
> drives, but haven't done much testing since I'll replace the adaptec
> (39160) because it's maxio is limited to 64k (while 53c1020 has 128k).
> sa(4) seems to work just fine with both drives, mt(1) showing "Reported

> File/Record Number" :-) No EOM tests done so far?

I'm glad it is working well for you! You can do larger I/O sizes with the
Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config
file. e.g.:

options MAXPHYS=(1024*1024)
options DFLTPHYS=(1024*1024)

If you set those values larger, you won't be able to do more than 132K with
the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33
segments * PAGE_SIZE.)

> I'll archive zfs streams, therefore I needed some kind of forward error
> correction. Probably people following this thread also have found to
> need this, therefore I'd like to point to the new port misc/vdmfec
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950
> Perhaps someone want's to take this bug report.

That looks cool. :) I'm not a ports committer, but hopefully one of them
will pick it up.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Harald Schmalzbauer]

Bezüglich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime):

…

>>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>>>
>>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

…

> I'm glad it is working well for you! You can do larger I/O sizes with the
> Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config
> file. e.g.:
>
> options MAXPHYS=(1024*1024)
> options DFLTPHYS=(1024*1024)
>
> If you set those values larger, you won't be able to do more than 132K with
> the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33
> segments * PAGE_SIZE.)

Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver
limitations corresponding to systems MAX/DFLTPHYS. I thought only
silicon limitations define it's value.
But in order to have a best matching pre-production test-environment, I
nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on
PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe,
which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge).

Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
LTO3 and DDS5)
With DDS5, densitiy is reported as "unknown". If I remember correctly,
you have your DDS4 reporting "DDS4"?

> > therefore I'd like to point to the new port misc/vdmfec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950

> That looks cool. :) I'm not a ports committer, but hopefully one of them
> will pick it up.

Cool it is indeed, but whether it's really usefull or not is beyond my
expertise. I couldn't collect much MT experience yet.
I know that LTO and similar "modern" MT technology do their own ECC (in
the meaning of erasure code, mostly Reed-Solomon).
What I don't know (but wanting to be best prepared for) is how arbitrary
LTO drives behave, if the one (1) in 10^17 bits was detected to be
uncorrectable.
If it wasn't detected, the post erasure code (vdmfec in that case) would
help for sure.
But If the drive just cuts the output, or stops streaming at all, vdmfec
was useless…

According to excerpts of "Study of Perpendicular AME Media in a Linear
Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS
has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So
with DDS, _every_ single block pax(1) writes to tape needs to be
internally corrected! Of course, nobody wants zfs' send output stream to
DDS, it's much too slow/small, but just to mention.

For archives of zfs streams, I don't feel safe relying on the tape
drives' FEC, which was designed for backup solutions which do their own
blocking+cheksumming, so the very seldom to expect uncorrectable read
error would at worst lead to some/single unrecoverable files – even in
case of database files most likely post-recoverable.
But with one flipped bit in the zfs stream, you'd loose hundred of
gigabytes, completely unrecoverable!
As long as the tape keeps spitting complete blocks, even in the case
when the tape knows that the output is not correct, vdmfec ought to be
the holy grail :-)

Going slightly more off topic:
One hot candidate for beeing another holy grail, is mbuffer(1) for me.

I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but
for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge
block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's
no problem to stream LTO-4 native rate with a tape-transport-blocksize
of 32k.
Btw, besides the FIFO-buffering, I'm missing star(1) also for it's
multi-volume support. tar(1) in base isn't really useful for tape
buddies – IMHO it's hardly adequate for any purpose and I don't
understand it's widespread usage… Most likely the absence of dump(8) for
zfs misleads to tar(1) ;-)

Were there ever thoughts about implementing FIFO-buffering into sa(4)?
We don't have mbuffer(1) in base, but I think, to complete FreeBSD's
tape support, users should find all technology/tools, needed for using
modern tape drives, in base. If sa(4) could provide sysctl-controlled
FIFO-buffering, some base tools were a bit more apropriate for tape
usage, I think.

Thanks,

-Harry

[Dan Langille]

> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>
> On Sat, Feb 14, 2015 at 18:22:43 -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.
>>
>> I have a DLT 8000 and an SDLT 220.
>>
>> I don't have anything running current, but I have a spare machine which I could use for testing.
>>
>> Do you see any value is tests with that hardware? I'd be testing it via Bacula.
>>
>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
>>
>
> Actually, yes. Bacula is a bit tricky to configure, so your trying it out
> would be helpful if you have the time.

I have been unable to test yet. I've encountered time and hardware issues.

I may be able to try tomorrow.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

On Fri, Feb 27, 2015 at 20:05:05 +0100, Harald Schmalzbauer wrote:
> Bez?glich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime):
>
> ?

> >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
> >>>
> >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

> ?

>
> > I'm glad it is working well for you! You can do larger I/O sizes with the
> > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config
> > file. e.g.:
> >
> > options MAXPHYS=(1024*1024)
> > options DFLTPHYS=(1024*1024)
> >
> > If you set those values larger, you won't be able to do more than 132K with
> > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33
> > segments * PAGE_SIZE.)
>
> Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver
> limitations corresponding to systems MAX/DFLTPHYS. I thought only
> silicon limitations define it's value.

It depends on the driver. I thought that the Adaptec drivers go off of
MAXPHYS (because that's what the driver author told me last week :), but
in looking at the code, they actually have a hard-coded value that can be
increased. You can bump AHC_MAXPHYS or AHD_MAXPHYS in aic7xxx_osm.h or
aic79xx_osm.h, respectively. In order to make any difference, though, you
would have to bump MAXPHYS/DFLTPHYS (so the sa(4) driver will use that
value) or change the ahc(4)/ahd(4) driver to set the maxio field in the
path inquiry CCB.

> But in order to have a best matching pre-production test-environment, I
> nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on
> PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe,
> which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge).

Okay. That should work.

> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
> LTO3 and DDS5)
> With DDS5, densitiy is reported as "unknown". If I remember correctly,
> you have your DDS4 reporting "DDS4"?

That means that we need to add DDS5 to the density table in libmt. Can
you send the output of 'mt status -v'? It would actually be helpful for
all three drives.

Also, do any of your drives give a full report for 'mt getdensity'? If so,
can you send that as well? (By full report, I mean more than one line.)

We don't have density codes for DDS-5/DAT 72, DAT 160 or DAT 320 yet. It
looks like DDS-5 should be 0x47.

> > > therefore I'd like to point to the new port misc/vdmfec
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950
> > That looks cool. :) I'm not a ports committer, but hopefully one of them
> > will pick it up.
>
> Cool it is indeed, but whether it's really usefull or not is beyond my
> expertise. I couldn't collect much MT experience yet.
> I know that LTO and similar "modern" MT technology do their own ECC (in
> the meaning of erasure code, mostly Reed-Solomon).
> What I don't know (but wanting to be best prepared for) is how arbitrary
> LTO drives behave, if the one (1) in 10^17 bits was detected to be
> uncorrectable.
> If it wasn't detected, the post erasure code (vdmfec in that case) would
> help for sure.
> But If the drive just cuts the output, or stops streaming at all, vdmfec

> was useless?

There is a difference in the uncorrectable bit error rate and the
undetectable bit error rate. The uncorrectable bit error rate for LTO-6 is
1 in 10^17. It is 1 in 10^19 for Oracle T10000 C/D drives, and 1 in 10^20
for IBM TS1150. Seagate Enterprise drives claim to have an uncorrectable
bit error rate of 1 sector per 10^15 bits read.

See:

http://www.oracle.com/us/products/servers-storage/storage/tape-storage/t10000c-reliability-wp-409919.pdf

http://www.spectralogic.com/index.cfm?fuseaction=home.displayFile&DocID=2513

http://www.seagate.com/www-content/product-content/enterprise-hdd-fam/enterprise-capacity-3-5-hdd/constellation-es-4/en-us/docs/enterprise-capacity-3-5-hdd-ds1791-8-1410us.pdf

The second white paper claims that tape has an undetectable bit error rate
of 1 in 1.6x10^33 bits. I assume it is referring to TS1150, but I don't
know for sure.

It is far more likely that your tape or tape drive will break than it is
that you would get a bad bit back from the drive.

> According to excerpts of "Study of Perpendicular AME Media in a Linear
> Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS
> has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So
> with DDS, _every_ single block pax(1) writes to tape needs to be
> internally corrected! Of course, nobody wants zfs' send output stream to
> DDS, it's much too slow/small, but just to mention.
>
> For archives of zfs streams, I don't feel safe relying on the tape
> drives' FEC, which was designed for backup solutions which do their own
> blocking+cheksumming, so the very seldom to expect uncorrectable read

> error would at worst lead to some/single unrecoverable files ? even in

> case of database files most likely post-recoverable.
> But with one flipped bit in the zfs stream, you'd loose hundred of
> gigabytes, completely unrecoverable!
> As long as the tape keeps spitting complete blocks, even in the case
> when the tape knows that the output is not correct, vdmfec ought to be
> the holy grail :-)

A tape drive or hard drive isn't going to return bits that it knows aren't
correct. They'll return an error instead. The bit error rate of a tape
drive is lower than the bit error rate for a hard drive, so you're less
likely to get bad bits back from a tape drive than a disk drive.

Another thing you have to consider, if you're concerned about the bit error
rates, is the error rate of the link that you're using to connect to the
tape or disk drive. The tape/disk might read the block correctly, but
you could also get corruption on the link.

This article talks about disk/tape bit error rates and the link bit error
rates. I haven't read the whole thing, but it should make for some
interesting reading:

http://www.enterprisestorageforum.com/storage-technology/sas-vs.-sata-1.html

With ZFS, you get protection from link and disk errors via its checksums
and RAID. If there is a checksum error on one drive, it can rebuild the
corrupted data using the parity/mirror information.

If you want to do the same thing with a tape drive, you would need to write
your data to two tapes, or have another copy somewhere that you could use
as your recovery copy in case of corruption.

FWIW, the sa(4) driver now supports protection information on a per-block
basis. LTO (at least newer drives) and TS drives support adding a CRC on
the end of each tape block written to and read from the drive. The drive
will verify it on writes, and supply the checksum on reads. You could also
do your own FEC scheme.

> Going slightly more off topic:
> One hot candidate for beeing another holy grail, is mbuffer(1) for me.
>
> I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but
> for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge
> block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's
> no problem to stream LTO-4 native rate with a tape-transport-blocksize
> of 32k.
> Btw, besides the FIFO-buffering, I'm missing star(1) also for it's
> multi-volume support. tar(1) in base isn't really useful for tape

> buddies ? IMHO it's hardly adequate for any purpose and I don't
> understand it's widespread usage? Most likely the absence of dump(8) for

> zfs misleads to tar(1) ;-)
>
> Were there ever thoughts about implementing FIFO-buffering into sa(4)?
> We don't have mbuffer(1) in base, but I think, to complete FreeBSD's
> tape support, users should find all technology/tools, needed for using
> modern tape drives, in base. If sa(4) could provide sysctl-controlled
> FIFO-buffering, some base tools were a bit more apropriate for tape
> usage, I think.

It would probably be easier and better to just put mbuffer in the base.

The challenge with doing buffering in the tape driver is that the userland
application would need to use a different API to write to the driver. The
standard write(2) API requires that it return status when the block is
written. So if we're going to buffer up a bunch of I/O in the
tape driver, we would need to do it with an async I/O type interface so
that we could return an individual error status for any I/O that fails.

If you're not able to stream to a tape drive with ZFS send, but it does
work with mbuffer, then the issue is just an inconsistent output rate from
ZFS send. mbuffer overcomes the consistency problem with buffering.
We could do the buffering in the kernel, but that would mean rewriting any
userland application that wants to talk to the tape drive.

[Kenneth D. Merry]

On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote:
>
> > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
> >
> > On Sat, Feb 14, 2015 at 18:22:43 -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.
> >>
> >> I have a DLT 8000 and an SDLT 220.
> >>
> >> I don't have anything running current, but I have a spare machine which I could use for testing.
> >>
> >> Do you see any value is tests with that hardware? I'd be testing it via Bacula.
> >>
> >> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
> >>
> >
> > Actually, yes. Bacula is a bit tricky to configure, so your trying it out
> > would be helpful if you have the time.
>
> I have been unable to test yet. I've encountered time and hardware issues.

I know how that goes! (On both counts.)

> I may be able to try tomorrow.

So I have tested building it and it does build at least. If you're able to
figure out some of the answers below, that would be great!

> ?
> Dan Langille
> http://langille.org/

>
>
>
>
>

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

> On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry <k...@FreeBSD.ORG> wrote:
>
> On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote:
>>
>>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>>>
>>> On Sat, Feb 14, 2015 at 18:22:43 -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.
>>>>
>>>> I have a DLT 8000 and an SDLT 220.
>>>>
>>>> I don't have anything running current, but I have a spare machine which I could use for testing.
>>>>
>>>> Do you see any value is tests with that hardware? I'd be testing it via Bacula.
>>>>
>>>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula committer.
>>>>
>>>
>>> Actually, yes. Bacula is a bit tricky to configure, so your trying it out
>>> would be helpful if you have the time.
>>
>> I have been unable to test yet. I've encountered time and hardware issues.
>
> I know how that goes! (On both counts.)

Hardware issues fixed. Now upgrading that zfsroot box from 9.2 to 10.1 RELEASE.

sudo freebsd-update -r 10.1-RELEASE upgrade

Then I'll grab sources, apply your 10 STABLE patches, and build world.

—
Dan Langille
http://langille.org/

[Dan Langille]

> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>
>
> I have updated the patches.
>
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
>
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies. (One of them mav did for me, thanks!)
>
> Rough draft commit message:
>
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>
> The patches against FreeBSD/head as of SVN revision 278975:
>
> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
>
> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>
> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

Not sure what I've done wrong here.

I've applied your patches and run make buildworld against:

[root@cuppy:/usr/src] # svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-west.freebsd.org/base/stable/10
Relative URL: ^/stable/10
Repository Root: https://svn0.us-west.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 278721
Node Kind: directory
Schedule: normal
Last Changed Author: ngie
Last Changed Rev: 278721
Last Changed Date: 2015-02-13 21:46:22 +0000 (Fri, 13 Feb 2015)

But I get:

rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> lib/libmp (cleandir)
rm -f Version.map libmp.3.gz libmp.3.cat.gz
rm -f a.out mpasbn.o mpasbn.o.tmp
rm -f mpasbn.po mpasbn.po.tmp
rm -f mpasbn.So mpasbn.so mpasbn.So.tmp
rm -f libmp.so
rm -f libmp.a libmp_p.a libmp.so.7
rm -f Version.map
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> lib/libmt (cleandir)
cd: /usr/src/lib/libmt: No such file or directory
*** Error code 2

Stop.
make[3]: stopped in /usr/src/lib
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

—
Dan Langille
http://langille.org/

[Dan Langille]

> On Feb 28, 2015, at 11:48 AM, Dan Langille <d...@langille.org> wrote:
>
>
>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>>
>>
>> I have updated the patches.
>>
>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
>> I committed those separately.
>>
>> I have (hopefully) fixed the build for the stable/10 patches by MFCing
>> dependencies. (One of them mav did for me, thanks!)
>>
>> Rough draft commit message:
>>
>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>>
>> The patches against FreeBSD/head as of SVN revision 278975:
>>
>> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
>>
>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>>
>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt
>
> Not sure what I've done wrong here.
>
> I've applied your patches and run make buildworld against:

It appears 'patch -p0' is my friend...

It's been a long time..

[Dan Langille]

> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>
>

> I have updated the patches.
>
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
>
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies. (One of them mav did for me, thanks!)
>
> Rough draft commit message:
>
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt

I have current installed and running with Bacula, but I have not tried the tape drive yet.

It seems like your changes are in there from about 5 days ago.

Having solved my server hardware issues, I'm now having issues with the autochanger mechanism
of the tape library.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote:
>
> > On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
> >
> >
> > I have updated the patches.
> >
> > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> > I committed those separately.
> >
> > I have (hopefully) fixed the build for the stable/10 patches by MFCing
> > dependencies. (One of them mav did for me, thanks!)
> >
> > Rough draft commit message:
> >
> > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>
>
> I have current installed and running with Bacula, but I have not tried the tape drive yet.
>

Thanks for all your work on this!

> It seems like your changes are in there from about 5 days ago.

Yes, that is correct.

> Having solved my server hardware issues, I'm now having issues with the autochanger mechanism
> of the tape library.

Does it work with chio(1)?

Does it look like hardware or software? (If it is software, I can help
with that.)

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

> On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry <k...@FreeBSD.ORG> wrote:
>
>> On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote:
>>
>>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>>>
>>>
>>> I have updated the patches.
>>>
>>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
>>> I committed those separately.
>>>
>>> I have (hopefully) fixed the build for the stable/10 patches by MFCing
>>> dependencies. (One of them mav did for me, thanks!)
>>>
>>> Rough draft commit message:
>>>
>>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>>
>>
>> I have current installed and running with Bacula, but I have not tried the tape drive yet.
>
> Thanks for all your work on this!
>
>> It seems like your changes are in there from about 5 days ago.
>
> Yes, that is correct.
>
>> Having solved my server hardware issues, I'm now having issues with the autochanger mechanism
>> of the tape library.
>
> Does it work with chio(1)?
>
> Does it look like hardware or software? (If it is software, I can help
> with that.)
>
>

Hardware. The screw drive for the tape robot is sticky. It can be moved by hand, but the motor in this DL 891 cannot. It might need lube. It was suspect last time I used it. Worst case, I will remove ins of the two DLT 8000 tape drives and load tapes manually.
--
Dan Langille
http://langille.org/

[Dan Langille]

> On Feb 28, 2015, at 6:42 PM, Dan Langille <d...@langille.org> wrote:
>
>> On Feb 28, 2015, at 6:15 PM, Kenneth D. Merry <k...@FreeBSD.ORG> wrote:
>>
>>> On Sat, Feb 28, 2015 at 17:29:48 -0500, Dan Langille wrote:
>>>
>>>> On Feb 18, 2015, at 7:13 PM, Kenneth D. Merry <k...@freebsd.org> wrote:
>>>>
>>>>
>>>> I have updated the patches.
>>>>
>>>> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
>>>> I committed those separately.
>>>>
>>>> I have (hopefully) fixed the build for the stable/10 patches by MFCing
>>>> dependencies. (One of them mav did for me, thanks!)
>>>>
>>>> Rough draft commit message:
>>>>
>>>> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>>>
>>>
>>> I have current installed and running with Bacula, but I have not tried the tape drive yet.
>>
>> Thanks for all your work on this!
>>
>>> It seems like your changes are in there from about 5 days ago.
>>
>> Yes, that is correct.
>>
>>> Having solved my server hardware issues, I'm now having issues with the autochanger mechanism
>>> of the tape library.
>>
>> Does it work with chio(1)?
>>
>> Does it look like hardware or software? (If it is software, I can help
>> with that.)
>>
>>
>
> Hardware. The screw drive for the tape robot is sticky. It can be moved by hand, but the motor in this DL 891 cannot. It might need lube. It was suspect last time I used it. Worst case, I will remove ins of the two DLT 8000 tape drives and load tapes manually.

A bit of lube, and we have POST: https://twitter.com/DLangille/status/572117570997919744

More, soon.

—

[Dan Langille]

# 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. :/





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

# 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


# 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?


Read below regarding two tape drives

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.

—
Dan Langille
http://langille.org/

[Dan Langille]

I have this in /usr/local/etc/bacula/bacula-sd.conf

Device {
Name = DLT
Description = "QUANTUM DLT7000 1624"
Media Type = DLT
Archive Device = /dev/nsa1

Autochanger = YES
Drive Index = 0

Offline On Unmount = no

Hardware End of Medium = yes

BSF at EOM = yes
Backward Space Record = no
Fast Forward Space File = no
TWO EOF = yes
}

FYI, http://www.freebsddiary.org/digital-tl891.php (from 2006) has a btape test on this same model.

Here's the test I ran tonight:

[root@cuppy:/usr/home/dan] # btape -c /usr/local/etc/bacula/bacula-sd.conf /dev/nsa1
Tape block granularity is 1024 bytes.
btape: butil.c:287-0 Using device: "/dev/nsa1" for writing.
btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK
*test

=== Write, rewind, and re-read test ===

I'm going to write 10000 records and an EOF
then write 10000 records and an EOF, then rewind,
and re-read the data to verify that it is correct.

This is an *essential* feature ...

btape: btape.c:1152-0 Wrote 10000 blocks of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1168-0 Wrote 10000 blocks of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1210-0 Rewind OK.
10000 blocks re-read correctly.
Got EOF on tape.
10000 blocks re-read correctly.
=== Test Succeeded. End Write, rewind, and re-read test ===

btape: btape.c:1277-0 Block position test
btape: btape.c:1289-0 Rewind OK.
Reposition to file:block 0:4
Block 5 re-read correctly.
Reposition to file:block 0:200
Block 201 re-read correctly.
Reposition to file:block 0:9999
Block 10000 re-read correctly.
Reposition to file:block 1:0
Block 10001 re-read correctly.
Reposition to file:block 1:600
Block 10601 re-read correctly.
Reposition to file:block 1:9999
Block 20000 re-read correctly.
=== Test Succeeded. End Write, rewind, and re-read test ===



=== Append files test ===

This test is essential to Bacula.

I'm going to write one record in file 0,
two records in file 1,
and three records in file 2

btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK
btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1420-0 Now moving to end of medium.
btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0.
We should be in file 3. I am at file 0. This is NOT correct!!!!

Append test failed. Attempting again.
Setting "Hardware End of Medium = no
and "Fast Forward Space File = no
and retrying append test.



=== Append files test ===

This test is essential to Bacula.

I'm going to write one record in file 0,
two records in file 1,
and three records in file 2

btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK
btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1420-0 Now moving to end of medium.
btape: btape.c:625-0 Moved to end of medium.
We should be in file 3. I am at file 3. This is correct!

Now the important part, I am going to attempt to append to the tape.

btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
Done appending, there should be no I/O errors

Doing Bacula scan of blocks:
1 block of 64448 bytes in file 1
End of File mark.
2 blocks of 64448 bytes in file 2
End of File mark.
3 blocks of 64448 bytes in file 3
End of File mark.
1 block of 64448 bytes in file 4
End of File mark.
Total files=4, blocks=7, bytes = 451,136
End scanning the tape.
We should be in file 4. I am at file 4. This is correct!


It looks like the test worked this time, please add:

Hardware End of Medium = No

Fast Forward Space File = No
to your Device resource in the Storage conf file.

The above Bacula scan should have output identical to what follows.
Please double check it ...
=== Sample correct output ===
1 block of 64448 bytes in file 1
End of File mark.
2 blocks of 64448 bytes in file 2
End of File mark.
3 blocks of 64448 bytes in file 3
End of File mark.
1 block of 64448 bytes in file 4
End of File mark.
Total files=4, blocks=7, bytes = 451,136
=== End sample correct output ===

If the above scan output is not identical to the
sample output, you MUST correct the problem
or Bacula will not be able to write multiple Jobs to
the tape.

Skipping read backwards test because BSR turned off.


=== Forward space files test ===

This test is essential to Bacula.

I'm going to write five files then test forward spacing

btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:1907-0 Wrote one record of 64412 bytes.
btape: btape.c:1909-0 Wrote block to device.
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:604-0 Wrote 1 EOF to "DLT" (/dev/nsa1)
btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1634-0 Now forward spacing 1 file.
We should be in file 1. I am at file 1. This is correct!
btape: btape.c:1646-0 Now forward spacing 2 files.
We should be in file 3. I am at file 3. This is correct!
btape: btape.c:574-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1659-0 Now forward spacing 4 files.
We should be in file 4. I am at file 4. This is correct!

btape: btape.c:1677-0 Now forward spacing 1 more file.
We should be in file 5. I am at file 5. This is correct!

=== End Forward space files test ===


Ah, I see you have an autochanger configured.
To test the autochanger you must have a blank tape
that I can write on in Slot 1.

Do you wish to continue with the Autochanger test? (y/n): y


=== Autochanger test ===

3301 Issuing autochanger "loaded" command.
Nothing loaded in the drive. OK.
3303 Issuing autochanger "load 1 0" command.
3303 Autochanger "load 1 0" status is OK.
btape: btape.c:469-0 open device "DLT" (/dev/nsa1): OK
btape: btape.c:1564-0 Rewound "DLT" (/dev/nsa1)
btape: btape.c:1571-0 Wrote EOF to "DLT" (/dev/nsa1)

The test autochanger worked!!

*

>
>> I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL.
>>
>
> Thanks! If there are additional features they would like out of the tape
> driver, I'm happy to talk about it. (Or help if they'd like to use the new
> status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.)

Errors are interesting to me. Especially corrected errors. They are a good indicator of tape quality.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

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.

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.

> ... 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'?

I would look at cabling and termination. Is this your library?

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.

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.

> ?
> Dan Langille
> http://langille.org/
>
>
>
>
>

[Dan Langille]

# 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>

>
> 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.

>
> 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.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

This is the critical piece. The test moves the tape to the end of the
medium. With hardware position information, you can tell what filemark
you're on. Without it, you can't.

> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on "DLT" (/dev/nsa1). ERR=No error: 0.
> We should be in file 3. I am at file 0. This is NOT correct!!!!
>
> Append test failed. Attempting again.
> Setting "Hardware End of Medium = no
> and "Fast Forward Space File = no
> and retrying append test.

This is not surprsing, given that the drive doesn't support long read
position data. (It's a SCSI-2 device.) So that means that Bacula will
need to do it manually.

Great, thanks for running the test! Looks like things are working as well
as they were before.

> >
> >> I'll let the other Bacula devs know about this. They deal with the hardware. I work on PostgreSQL.
> >>
> >
> > Thanks! If there are additional features they would like out of the tape
> > driver, I'm happy to talk about it. (Or help if they'd like to use the new
> > status reporting ioctl, MTIOCEXTGET or any of the other new ioctls.)
>
> Errors are interesting to me. Especially corrected errors. They are a good indicator of tape quality.
>

Yes. At least on modern drives, there is a good bit available in the log
pages. You can try seeing what logs your drive supports by installing the
sg3_utils package and running 'sg_logs sa1 --all'.

Given the large amount of data available on some drives, and the difficulty
distilling it down to a clear good/bad, I probably won't stick that in the
'mt status' output.

But you can certainly take a look at it and have an idea of whether your
particular tape/drive are experiencing issues.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Kenneth D. Merry]

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.

[Dan Langille]

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

—
Dan Langille
http://langille.org/

[Dan Langille]

Yes, I have nothing newer than SCSI-2. Even my SDLT is SCSI-2 but that
tape library is hooked up to a different computer and was doing backups today.

That's a lot of output: https://gist.github.com/dlangille/0e15a7fbf7acab56fd32

I will run some Bacula jobs soon. I'm still setting up config files.

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

Okay. Well, no indication of what happened. Perhaps boot -v will show it,
perhaps not.

[Kenneth D. Merry]

So, here is one thing that we can try to see whether these drives support
long position information, even though they only claim to be SCSI-2. If
they do, we can potentially add a quirk (or autodetection) to enable it.
The code currently doesn't bother asking drives that claim to be SCSI-2
for long position information. (Because that feature was added in the
SSC spec, which came after SCSI-2.)

Issue a READ POSITION with the short form specified:

camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd

Issue a READ POSITION with the vendor-specific block numbers:

camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd

Issue a READ POSITION with the long form data:

camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd

If it supports the last one, then I can put a quirk (or autodetection) in
the driver and Bacula will get the hardware filemarks. You should try this
on your SDLT as well. It may well support it.

Google didn't quickly produce a SCSI manual for the DEC drive, but the
Quantum SDLT manual indicates that it supports long position data, despite
identifying itself as a SCSI-2 drive.

That is a lot.

> I will run some Bacula jobs soon. I'm still setting up config files.

Thanks for all the testing, I really appreciate it!

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

Sadly, no:

[root@cuppy:~] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 |....|
00000014
[root@cuppy:~] # camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd
00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 |....|
00000014
[root@cuppy:~] # camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
camcontrol: error sending command
(pass2:ahc0:0:2:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00
(pass2:ahc0:0:2:0): CAM status: SCSI Status Error
(pass2:ahc0:0:2:0): SCSI status: Check Condition
(pass2:ahc0:0:2:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB)
(pass2:ahc0:0:2:0): Command byte 1 bit 2 is invalid
[root@cuppy:~] #


The SDLT server is on 9.3 though:

[root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
cam_lookup_pass: No such file or directory
cam_lookup_pass: either the pass driver isn't in your kernel
cam_lookup_pass: or sa1 doesn't exist
[root@knew:/usr/home/dan] # uname -a
FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0: Tue Feb 24 21:28:03 UTC 2015 ro...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[root@knew:/usr/home/dan] #


It took me a while to figure that out... there is no sa1 on *this* system.

But, my SDLT:

[root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 |....|
00000014
[root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd
00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 |....|
00000014
[root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020
[root@knew:/usr/home/dan] #

—
Dan Langille
http://langille.org/

[Kenneth D. Merry]

Okay. Not too surprising I suppose.

> The SDLT server is on 9.3 though:
>
> [root@knew:/usr/home/dan] # camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
> camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed
> cam_lookup_pass: No such file or directory
> cam_lookup_pass: either the pass driver isn't in your kernel
> cam_lookup_pass: or sa1 doesn't exist
> [root@knew:/usr/home/dan] # uname -a
> FreeBSD knew.unixathome.org 9.3-RELEASE-p10 FreeBSD 9.3-RELEASE-p10 #0: Tue Feb 24 21:28:03 UTC 2015 ro...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
> [root@knew:/usr/home/dan] #
>
>
> It took me a while to figure that out... there is no sa1 on *this* system.
>
> But, my SDLT:
>
> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000010 00 00 00 00 |....|
> 00000014
> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd
> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000010 00 00 00 00 |....|
> 00000014
> [root@knew:/usr/home/dan] # camcontrol cmd sa0 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
> 00000000 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 00000020
> [root@knew:/usr/home/dan] #

Just to confirm, can you send the output of:

camcontrol inquiry sa0 -v

I want to make certain it reports that it is SCSI-2. If so, I'll change
the check in the driver to try asking for long position information on
SCSI-2 devices. If it fails, it'll fall back to the regular method.

> ?
> Dan Langille
> http://langille.org/
>
>
>
>
>

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

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/

[Dan Langille]

[dan@knew:~] $ sudo camcontrol inquiry sa0 -v
pass10: <COMPAQ SuperDLT1 5F5F> Removable Sequential Access SCSI-2 device
pass10: Serial Number CXB46H0716
pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
[dan@knew:~] $

—
Dan Langille
http://langille.org/

[Dan Langille]

> 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.

This came to me today via the Bacula mailing lists.

http://marc.info/?l=bacula-users&m=142531236722693&w=2

> As far as I can tell ltfs support on linux sits on top of the standard mt-st stuff \
> as a userspace (fuse) filesystem
> I'd hope it's much the same with BSD. Removing the standard interface would be \
> counterproductive overall

Can you answer that and I'll relay please?

[Kenneth D. Merry]

Ahh, good. Glad it is working now!

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Kenneth D. Merry]

Okay. Doing the check doesn't cause any problems on my collection of old
tape drives, so I'll go ahead and enable checking on SCSI-2 devices.

The primary thing is just making sure it doesn't cause tape drive to choke
if we request long position information. It doesn't appear to be an
issue. If we do run into one, we can put in a quirk.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Kenneth D. Merry]

On Mon, Mar 02, 2015 at 11:45:59 -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.
>
> This came to me today via the Bacula mailing lists.
>
> http://marc.info/?l=bacula-users&m=142531236722693&w=2
>
> > As far as I can tell ltfs support on linux sits on top of the standard mt-st stuff \
> > as a userspace (fuse) filesystem
> > I'd hope it's much the same with BSD. Removing the standard interface would be \
> > counterproductive overall
>
> Can you answer that and I'll relay please?

Sure. In short, the current interface will stay in place. I have added
additional ioctls that provide more features and information, but I don't
see any issue with leaving the current ioctls in place.

The MTIOCGET ioctl even gets an improvement in behavior when the tape drive
supports long position information -- it will report the file number after
a 'mt eod'.

IBM's LTFS sits on top of their own Linux tape driver, and operates with
a combination of tape driver ioctls (e.g. the standard MTIOTCOP ioctls)
and SCSI passthrough.

When I ported it to FreeBSD, I ran into several areas where we needed
more information out of the tape driver. So that was the primary
motivation behind adding the additional features. (Other features I
implemented using SCSI passthrough.)

He is correct that it runs with FUSE, although it can be linked into an
application as a library as well.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

Does this mean much to you?

Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f
Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f
Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Sending SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: (ahc0:A:2:0): Received SDTR period 19, offset f
Mar 2 19:42:59 cuppy kernel: Filtered to period 19, offset f


I'm having trouble with labeling barcodes from Bacula and the above is seen in /var/log/messages

—
Dan Langille
http://langille.org/

[Dan Langille]

The barcodes issue is resolved. I changed to using drive 0 instead of drive 1, now that we have both drives.

*label barcodes slots=3,4
The defined Storage resources are:
1: File1
2: OldTL891
Select Storage resource (1-2): 2
Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ...
3306 Issuing autochanger "slots" command.
Device "DTL03" has 10 slots.
Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ...
3306 Issuing autochanger "list" command.
The following Volumes will be labeled:
Slot Volume
==============
3 FAI261
4 FAI262
Do you want to label these Volumes? (yes|no): yes
Defined Pools:
1: Default
2: File
3: MYDLT
4: Scratch
Select the Pool (1-4): 4
Connecting to Storage daemon OldTL891 at 10.55.0.18:9103 ...
Sending label command for Volume "FAI261" Slot 3 ...
3000 OK label. VolBytes=64512 DVD=0 Volume="FAI261" Device="DTL03" (/dev/nsa0)
Catalog record for Volume "FAI261", Slot 3 successfully created.
Sending label command for Volume "FAI262" Slot 4 ...
3307 Issuing autochanger "unload slot 3, drive 0" command.
3304 Issuing autochanger "load slot 4, drive 0" command.
3305 Autochanger "load slot 4, drive 0", status is OK.
3000 OK label. VolBytes=64512 DVD=0 Volume="FAI262" Device="DTL03" (/dev/nsa0)
Catalog record for Volume "FAI262", Slot 4 successfully created.
*list volumes
Pool: Default
No results to list.
Pool: File
+---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| mediaid | volumename | volstatus | enabled | volbytes | volfiles | volretention | recycle | slot | inchanger | mediatype | lastwritten |
+---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+
| 1 | Vol-0001 | Append | 1 | 19,835,982 | 0 | 31,536,000 | 1 | 0 | 0 | File1 | 2015-03-02 17:50:40 |
| 2 | Vol-0002 | Append | 1 | 0 | 0 | 31,536,000 | 1 | 0 | 0 | DLT | |
+---------+------------+-----------+---------+------------+----------+--------------+---------+------+-----------+-----------+---------------------+
Pool: MYDLT
No results to list.
Pool: Scratch
+---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+
| mediaid | volumename | volstatus | enabled | volbytes | volfiles | volretention | recycle | slot | inchanger | mediatype | lastwritten |
+---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+
| 4 | FAI260 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 1 | 1 | DLT | |
| 5 | FAI263 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 2 | 1 | DLT | |
| 7 | FAI261 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 3 | 1 | DLT | |
| 8 | FAI262 | Append | 1 | 64,512 | 0 | 31,536,000 | 1 | 4 | 1 | DLT | |
+---------+------------+-----------+---------+----------+----------+--------------+---------+------+-----------+-----------+-------------+
*

But this is what arrives in /var/log/messages during the above:

Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f
Mar 2 20:29:06 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f
Mar 2 20:29:06 cuppy kernel: Filtered to period 19, offset f
Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f
Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f
Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f
Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f
Mar 2 20:30:22 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f
Mar 2 20:30:22 cuppy kernel: Filtered to period 19, offset f
Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f
Mar 2 20:30:59 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f
Mar 2 20:30:59 cuppy kernel: Filtered to period 19, offset f
Mar 2 20:30:59 cuppy kernel: xpt_release_devq(): requested 1 > present 0
Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Sending SDTR period 19, offset f
Mar 2 20:31:07 cuppy kernel: (ahc0:A:1:0): Received SDTR period 19, offset f
Mar 2 20:31:07 cuppy kernel: Filtered to period 19, offset f

Anything to be concerned about?

[Dan Langille]

When adding a 2nd job to a tape:

02-Mar 21:29 cuppy-sd JobId 19: Error: Unable to position to end of data on tape device "DTL03" (/dev/nsa0): ERR=tape_dev.c:345 ioctl MTIOCGET error on "DTL03" (/dev/nsa0). ERR=No error: 0.

I've gotten this on three consecutive tapes. NOTE: These *are* tapes I no longer use because of higher rates of corrected errors.

The problem seems to be locating the end of the data.

I can run a 4 or 5 jobs in a row, but if I restore a job, then add a job, it fails with the above message.

[Kenneth D. Merry]

Do you have 'Hardware End of Medium = no' in the configuration file?

In looking at the code, it may be set to yes, and that could be the issue
here.

>
> I can run a 4 or 5 jobs in a row, but if I restore a job, then add a job, it fails with the above message.
>

I would expect that on these particular tape drives because they don't
support long position information.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Dan Langille]

I had it set to yes. Now I'm testing with no and I do not encounter that error.

>> I can run a 4 or 5 jobs in a row, but if I restore a job, then add a job, it fails with the above message.
>>
>
> I would expect that on these particular tape drives because they don't
> support long position information.

Ahh, good.
—
Dan Langille
http://langille.org/

[Harald Schmalzbauer]

Bezüglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime):

> I have updated the patches.
>
> I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> I committed those separately.
>
> I have (hopefully) fixed the build for the stable/10 patches by MFCing
> dependencies. (One of them mav did for me, thanks!)
>

> Rough draft commit message:
>
> http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
>
> The patches against FreeBSD/head as of SVN revision 278975:
>
> http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
>
> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
>
> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt

Hello,

on 26/02/2105, r278964 seems to be part from the sa_changes patchset.
Do you have a sa_changes.stable_10.20150226 ready?
Or is it just a matter of exluding all parts, comitted with r278964
from the patchset?
I've done so in the mean while:
ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/sa_changes.stable_10.20150226.fudge.patch

Noticed that in sys/dev/mps/mps_sas.c 'cdai.flags' gets conditionally
(#if __FreeBSD_version >= 1100061) the new "CDAI_FLAG_NONE", while in
sbin/camcontrol/camcontrol.c, this is unconditionally used. Haven't
really looked at the code, mostly because my skills wouldN#t allow me to
answer this qusteion myself, but is that versioncheck in mps_sas.c still
vaild with the rest of the sa_driver-changes?

Thanks,

-Harry

[Harald Schmalzbauer]

Bezüglich Kenneth D. Merry's Nachricht vom 28.02.2015 01:08 (localtime):
…
>> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
>> LTO3 and DDS5)
>> With DDS5, densitiy is reported as "unknown". If I remember correctly,
>> you have your DDS4 reporting "DDS4"?
> That means that we need to add DDS5 to the density table in libmt. Can
> you send the output of 'mt status -v'? It would actually be helpful for
> all three drives.

Hello,

I'd like to present some test results.
All tests were done with 10-stable-r273923 and Ken's
sa_driver_changes-patchset, reduced by the commited scsi-sys-code.

Unfortunately, there's a problem with appending files to any SLRtape. I
can write the first file, but trying to open a second file for writing,
results in "end of device" message. This problem doesn't exist for other
drives (tested on VXA-2 (also SCSI-2) and DAT72 (SCSI-3)) with exactly
same environment (all currently connected SCSI drives (7) are on one
mpt(4) bus).
After the first "end of device" message, consecutive write attempts lead
to "Operation not permitted".

According to the datasheet
(http://www.tandbergdata.ru/products/files/SLR140_DS_605_ENG.pdf), the
drive should speak SCSI-3, but camcontrol shows SCSI-2.

##################
TandbergData SLR140 Drive
##################
camcontrol inq $TAPE -v
pass3: <TANDBERG SLR140 0605> Removable Sequential Access SCSI-2 device
pass3: Serial Number SN140253489
pass3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Command
Queueing Enabled

Density 0x36 = ALRF-6, 186000 bpi, SLR140 drive + SLR140tape:
SLRtape140 (8mm DualReel, 70GB native, 505.9m length, 5.5MiB/s)
mt status -v
Drive: sa3: <TANDBERG SLR140 0605> Serial Number: SN140253489

---------------------------------
Mode Density Blocksize bpi Compression

Current: 0x36:UNKNOWN variable 0 enabled (0x3)

---------------------------------
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

---------------------------------
Tape I/O parameters:
Maximum I/O size allowed by driver and controller (maxio): 131072 bytes
Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
Maximum block size supported by tape drive and media (max_blk): 262144 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): 131072 bytes

Minimum blocksize to reach highest throughput, thus sustained write of
uncompressable data (from /dev/random): 2...@5.5MiB/s

mt status

---------------------------------
Current Driver State: at rest.
---------------------------------

Partition: 0 Calc File Number: 1 Calc Record Number: 0

Residual: 0 Reported File Number: -1 Reported Record Number: -1
Flags: None

"short READ POSITION"
camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd
00000000 30 00 00 00 00 00 06 83 00 00 00 00 00 00 00 00 |0...............|

00000010 00 00 00 00 |....|
00000014

"vendor READ POSITION"
camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd
camcontrol: error sending command
(pass3:mpt1:0:13:0): READ POSITION. CDB: 34 01 00 00 00 00 00 00 00 00
(pass3:mpt1:0:13:0): CAM status: SCSI Status Error
(pass3:mpt1:0:13:0): SCSI status: Check Condition
(pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
in CDB)
(pass3:mpt1:0:13:0): Command byte 1 bit 0 is invalid
"long READ POSITION"
camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
camcontrol: error sending command
(pass3:mpt1:0:13:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00
(pass3:mpt1:0:13:0): CAM status: SCSI Status Error
(pass3:mpt1:0:13:0): SCSI status: Check Condition
(pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
in CDB)
(pass3:mpt1:0:13:0): Command byte 1 bit 2 is invalid

Different tapes
----------------------
Density 0x34 = ALRF-1, 15400 bpi:
SLRtape100 (8mm DualReel, 50GB native, 457.2m length, 4.7MiB/s)
SLRtape40 (8mm DualReel, 20GB native, 187,5m length, 4.7MiB/s)

Mode Density Blocksize bpi Compression

Current: 0x36:UNKNOWN variable 0 enabled (0x3)

Density 0x30 = MLR3, 103124 bpi:
SLRtape50 (¼" (Quarter inch) DualReel, 25GB native, 457.2m length, 1.8MiB/s)

##########
Exabyte VXA-2
##########
camcontrol inq $TAPE -v
pass9: <EXABYTE VXA-2 1009> Removable Sequential Access SCSI-2 device
pass9: Serial Number 0085105377
pass9: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command
Queueing Enabled

Density 0x81 = ??? (no info about areal density found, nor bpi/ftpi)
VXA-2 Drive + V10 Tape
VXA V10 (8mm DualReel, 20GB native, 120m length, 5.6MiB/s)
mt status -v
Drive: sa4: <EXABYTE VXA-2 1009> Serial Number: 0085105377

---------------------------------
Mode Density Blocksize bpi Compression

Current: 0x81:UNKNOWN variable 0 enabled (0x3)

---------------------------------
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

---------------------------------
Tape I/O parameters:
Maximum I/O size allowed by driver and controller (maxio): 131072 bytes
Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
Maximum block size supported by tape drive and media (max_blk): 245760 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): 131072 bytes

Minimum blocksize to reach highest throughput, thus sustained write of
uncompressable data (from /dev/random): 2...@5.6MiB/s

mt status

---------------------------------
Current Driver State: at rest.
---------------------------------

Partition: 0 Calc File Number: 4 Calc Record Number: 0

Residual: 0 Reported File Number: -1 Reported Record Number: -1
Flags: None

"short READ POSITION"
camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd
00000000 00 00 00 00 00 00 39 39 00 00 00 00 00 00 00 00 |......99........|
*
00000010

"vendor READ POSITION"
camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd
00000000 00 00 00 00 00 00 39 39 00 00 00 00 00 00 00 00 |......99........|
*
00000010

"long READ POSITION"
camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
camcontrol: error sending command
(pass9:mpt1:0:15:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00
(pass9:mpt1:0:15:0): CAM status: SCSI Status Error
(pass9:mpt1:0:15:0): SCSI status: Check Condition
(pass9:mpt1:0:15:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
in CDB)
(pass9:mpt1:0:15:0): Command byte 1 bit 2 is invalid

No other tape cartridges available for testing at the moment (X6 to
follow together with VXA-320 drive results)

################
Seagate/Quantum DAT72 (DDS-5)
################
camcontrol inq $TAPE -v
pass0: <SEAGATE DAT DAT72-052 A16K> Removable Sequential Access SCSI-3
device
pass0: Serial Number HV082SN
pass0: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command
Queueing Enabled

Density 0x47 = PRML, 162000 bpi, DAT72 Drive + DAT72 media
DAT-72 Cartridge (3.81mm DualReel, 36GB native, 170m length, 3.2MiB/s):
mt status -v
Drive: sa0: <SEAGATE DAT DAT72-052 A16K> Serial Number: HV082SN

---------------------------------
Mode Density Blocksize bpi Compression

Current: 0x47:UNKNOWN variable 0 enabled (DCLZ)

---------------------------------
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): 131072 bytes
Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
Maximum block size supported by tape drive and media (max_blk): 16777215

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): 131072 bytes

Minimum blocksize to reach highest throughput, thus sustained write of
uncompressable data (from /dev/random): <4...@3.2MiB/s

mt status

---------------------------------
Current Driver State: at rest.
---------------------------------

Partition: 0 Calc File Number: 7 Calc Record Number: 0
Residual: 0 Reported File Number: 7 Reported Record Number: 115634

"short READ POSITION"
camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd
00000000 30 00 00 00 00 01 c3 b2 00 01 c3 b2 00 00 00 00 |0...............|

00000010 00 00 00 00 |....|
00000014

"vendor READ POSITION"
camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd
00000000 30 00 00 00 00 01 c3 ab 00 01 c3 ab 00 00 00 00 |0...............|

00000010 00 00 00 00 |....|
00000014

"long READ POSITION"
camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 01 c3 b2 |................|
00000010 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 |................|
00000020

Different tapes
----------------------
Density 0x26 = PRML, 122000 bpi
DDS4 Cartridge (3.81mm DualReel, 20GB native, 150m length,):

Mode Density Blocksize bpi Compression

Current: 0x26:DDS-4 variable 97000 enabled (DCLZ)

Density 0x25 = PRML, 122000 bpi
(3.81mm DualReel, 36GB native, 125m length, )

Mode Density Blocksize bpi Compression

Current: 0x25:DDS-3 variable 97000 enabled (DCLZ)


I could also provide LTO-3 (and LTO-2) results – after I identified the
U320 killer in the bus…
Like reported earlier, LTO-2 worked like a charm.
DLT-V4 and VXA-320 will follow soon too – I'm waiting for some media.

Thanks,

-Harry

[Kenneth D. Merry]

On Sat, Mar 07, 2015 at 14:30:26 +0100, Harald Schmalzbauer wrote:
> Bez?glich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime):

> > I have updated the patches.
> >
> > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since
> > I committed those separately.
> >
> > I have (hopefully) fixed the build for the stable/10 patches by MFCing
> > dependencies. (One of them mav did for me, thanks!)
> >
> > Rough draft commit message:
> >
> > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt
> >
> > The patches against FreeBSD/head as of SVN revision 278975:
> >
> > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt
> >
> > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974:
> >
> > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt
>
> Hello,
>
> on 26/02/2105, r278964 seems to be part from the sa_changes patchset.
> Do you have a sa_changes.stable_10.20150226 ready?

I haven't done it yet, sorry.

> Or is it just a matter of exluding all parts, comitted with r278964
> from the patchset?
> I've done so in the mean while:
> ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/sa_changes.stable_10.20150226.fudge.patch
>

Thanks!

> Noticed that in sys/dev/mps/mps_sas.c 'cdai.flags' gets conditionally
> (#if __FreeBSD_version >= 1100061) the new "CDAI_FLAG_NONE", while in
> sbin/camcontrol/camcontrol.c, this is unconditionally used. Haven't
> really looked at the code, mostly because my skills wouldN#t allow me to
> answer this qusteion myself, but is that versioncheck in mps_sas.c still
> vaild with the rest of the sa_driver-changes?

Yes, that's intentional. The mps(4) and mpr(4) drivers are also maintained
outside the tree by LSI/Avago. I usually try to put version checks in
there, so that things work when they try to compile against earlier
releases. Otherwise they'd be putting in the same checks themselves. It
is easier to do them when the changes go in the tree.

camcontrol(8), on the other hand, is only maintained in the FreeBSD tree.
So it only ever needs to build against the FreeBSD branch it is in.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG

[Kenneth D. Merry]

On Wed, Mar 11, 2015 at 20:26:49 +0100, Harald Schmalzbauer wrote:
> Bez?glich Kenneth D. Merry's Nachricht vom 28.02.2015 01:08 (localtime):
> ?

> >> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
> >> LTO3 and DDS5)
> >> With DDS5, densitiy is reported as "unknown". If I remember correctly,
> >> you have your DDS4 reporting "DDS4"?
> > That means that we need to add DDS5 to the density table in libmt. Can
> > you send the output of 'mt status -v'? It would actually be helpful for
> > all three drives.
>
> Hello,
>
> I'd like to present some test results.
> All tests were done with 10-stable-r273923 and Ken's
> sa_driver_changes-patchset, reduced by the commited scsi-sys-code.

Thank you for testing all of these drives and media! I really appreciate
it!

> Unfortunately, there's a problem with appending files to any SLRtape. I
> can write the first file, but trying to open a second file for writing,
> results in "end of device" message. This problem doesn't exist for other
> drives (tested on VXA-2 (also SCSI-2) and DAT72 (SCSI-3)) with exactly
> same environment (all currently connected SCSI drives (7) are on one
> mpt(4) bus).
> After the first "end of device" message, consecutive write attempts lead
> to "Operation not permitted".
>
> According to the datasheet
> (http://www.tandbergdata.ru/products/files/SLR140_DS_605_ENG.pdf), the
> drive should speak SCSI-3, but camcontrol shows SCSI-2.
>
> ##################
> TandbergData SLR140 Drive
> ##################
> camcontrol inq $TAPE -v
> pass3: <TANDBERG SLR140 0605> Removable Sequential Access SCSI-2 device
> pass3: Serial Number SN140253489
> pass3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Command
> Queueing Enabled

This sounds like it could be an End Of Tape (EOT) model issue. There is a
quirk entry in the driver for other SLR drives, but it probably won't match
this particular drive because of a leading space in the INQUIRY data:

{
{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "TANDBERG",
" SLR*", "*"}, SA_QUIRK_1FM, 0
},

So, try doing a 'mt geteotmodel' on that drive. It is probably set to 2
filemarks. If it is, do:

mt seteotmodel 1

Obviously, if it is set to 1, try 2 and see what happens.

If that is the case, we can adjust the quirk to match that drive.

> Density 0x36 = ALRF-6, 186000 bpi, SLR140 drive + SLR140tape:
> SLRtape140 (8mm DualReel, 70GB native, 505.9m length, 5.5MiB/s)

Do you have any source documentation for the BPI data? Any information
on the number of tracks or the other fields that might go in the mt(1) man
page? (We can obviously put it in with that, it's just nice to put it all
in if we have it.)

> mt status -v
> Drive: sa3: <TANDBERG SLR140 0605> Serial Number: SN140253489
> ---------------------------------
> Mode Density Blocksize bpi Compression
> Current: 0x36:UNKNOWN variable 0 enabled (0x3)
> ---------------------------------
> 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
> ---------------------------------
> Tape I/O parameters:
> Maximum I/O size allowed by driver and controller (maxio): 131072 bytes
> Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
> Maximum block size supported by tape drive and media (max_blk): 262144 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): 131072 bytes
>
> Minimum blocksize to reach highest throughput, thus sustained write of
> uncompressable data (from /dev/random): 2...@5.5MiB/s

That's pretty good!

Good to know that it doesn't support long position information.

> Different tapes
> ----------------------
> Density 0x34 = ALRF-1, 15400 bpi:
> SLRtape100 (8mm DualReel, 50GB native, 457.2m length, 4.7MiB/s)
> SLRtape40 (8mm DualReel, 20GB native, 187,5m length, 4.7MiB/s)

Hmm, that is a vast difference in bpi between 0x34 and 0x36. 186000 for
0x36 (close to LTO-2), and 15400 for 0x34 (close to QIC-320). Is one of
thoes incorrect?

> Mode Density Blocksize bpi Compression
> Current: 0x36:UNKNOWN variable 0 enabled (0x3)
>
> Density 0x30 = MLR3, 103124 bpi:

> SLRtape50 (?" (Quarter inch) DualReel, 25GB native, 457.2m length, 1.8MiB/s)

>
> ##########
> Exabyte VXA-2
> ##########
> camcontrol inq $TAPE -v
> pass9: <EXABYTE VXA-2 1009> Removable Sequential Access SCSI-2 device
> pass9: Serial Number 0085105377
> pass9: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command
> Queueing Enabled
>
> Density 0x81 = ??? (no info about areal density found, nor bpi/ftpi)
> VXA-2 Drive + V10 Tape
> VXA V10 (8mm DualReel, 20GB native, 120m length, 5.6MiB/s)

I'll look around and see if I can dig anything up on that.

So, no long position information there either.

> No other tape cartridges available for testing at the moment (X6 to
> follow together with VXA-320 drive results)
>
> ################
> Seagate/Quantum DAT72 (DDS-5)
> ################
> camcontrol inq $TAPE -v
> pass0: <SEAGATE DAT DAT72-052 A16K> Removable Sequential Access SCSI-3
> device
> pass0: Serial Number HV082SN
> pass0: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command
> Queueing Enabled
>
> Density 0x47 = PRML, 162000 bpi, DAT72 Drive + DAT72 media
> DAT-72 Cartridge (3.81mm DualReel, 36GB native, 170m length, 3.2MiB/s):

I have that one in FreeBSD/head, so it will go into stable/10 with the rest
of the changes.

Ahh, so it does support long read position data. :)

> Different tapes
> ----------------------
> Density 0x26 = PRML, 122000 bpi
> DDS4 Cartridge (3.81mm DualReel, 20GB native, 150m length,):
> Mode Density Blocksize bpi Compression
> Current: 0x26:DDS-4 variable 97000 enabled (DCLZ)
>
> Density 0x25 = PRML, 122000 bpi
> (3.81mm DualReel, 36GB native, 125m length, )
> Mode Density Blocksize bpi Compression
> Current: 0x25:DDS-3 variable 97000 enabled (DCLZ)

Great, thanks!

> I could also provide LTO-3 (and LTO-2) results ? after I identified the
> U320 killer in the bus?

> Like reported earlier, LTO-2 worked like a charm.

> DLT-V4 and VXA-320 will follow soon too ? I'm waiting for some media.

Thanks for all of the testing! I appreciate it!

[Dan Langille]

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
> k...@FreeBSD.ORG

—
Dan Langille
http://langille.org/





_______________________________________________
freebs...@freebsd.org mailing list

https://lists.freebsd.org/mailman/listinfo/freebsd-scsi

[Kenneth D. Merry]

Yes, it's informational. It tells you that your tape blocks are 64512
bytes long. Or at least the first one is.

The initial tape mount inside the sa(4) driver does a test read with an 8K
buffer. This is to get the drive to actually look at the media, so it will
know what is there. (This is necessary on some older drives.)

We don't necessarily expect that the initial read will read in a whole
block, but the sense data that comes back from the tape drive will tell you
how big the first block is at least.

We could silence it, or perhaps use a bigger (e.g. MAXPHYS) buffer, so
you'd get an error in the case where we can't read the blocksize written
to the tape. I think it is somewhat helpful to know how big the blocksize
is.

Ken
--
Kenneth Merry
k...@FreeBSD.ORG