Re: sa(4) driver changes available for test

On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote:
> 
> > On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <ken_at_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 <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.
> 
> 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!

> > 
> > 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
> 
> ? 
> Dan Langille
> http://langille.org/
> 
> 
> 
> 
> 

Ken
-- 
Kenneth Merry
ken_at_FreeBSD.ORG