Re: sa(4) driver changes available for test

On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
> 
> > On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry <ken_at_freebsd.org> wrote:
> > 
> > 
> > I have a fairly large set of changes to the sa(4) driver and mt(1) driver
> > that I'm planning to commit in the near future.
> > 
> > A description of the changes is here and below in this message.
> > 
> > If you have tape hardware and the inclination, I'd appreciate testing and
> > feedback.
> 
> 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_at_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_at_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
ken_at_FreeBSD.ORG