Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Feb 2015 10:53:18 -0500
From:      Dan Langille <dan@langille.org>
To:        "Kenneth D. Merry" <ken@FreeBSD.ORG>
Cc:        current@freebsd.org, scsi@freebsd.org
Subject:   Re: sa(4) driver changes available for test
Message-ID:  <36E25B53-8D76-4409-87FD-5E0369A4A513@langille.org>
In-Reply-To: <20150228064756.GA40281@mithlond.kdm.org>
References:  <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <5568AE5F-193C-47A8-A24B-FB2C36E37BC9@langille.org> <20150228064756.GA40281@mithlond.kdm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Feb 28, 2015, at 1:47 AM, Kenneth D. Merry <ken@FreeBSD.ORG> wrote:
>=20
> On Fri, Feb 27, 2015 at 17:56:42 -0500, Dan Langille wrote:
>>=20
>>> On Feb 17, 2015, at 1:36 PM, Kenneth D. Merry <ken@freebsd.org> =
wrote:
>>>=20
>>> On Sat, Feb 14, 2015 at 18:22:43 -0500, Dan Langille wrote:
>>>>=20
>>>>> On Feb 13, 2015, at 7:32 PM, Kenneth D. Merry <ken@freebsd.org> =
wrote:
>>>>>=20
>>>>>=20
>>>>> I have a fairly large set of changes to the sa(4) driver and mt(1) =
driver
>>>>> that I'm planning to commit in the near future.
>>>>>=20
>>>>> A description of the changes is here and below in this message.
>>>>>=20
>>>>> If you have tape hardware and the inclination, I'd appreciate =
testing and
>>>>> feedback.
>>>>=20
>>>> I have a DLT 8000 and an SDLT 220.
>>>>=20
>>>> I don't have anything running current, but I have a spare machine =
which I could use for testing.
>>>>=20
>>>> Do you see any value is tests with that hardware? I'd be testing it =
via Bacula.
>>>>=20
>>>> disclosure: I'm the sysutils/bacula-* maintainer and a Bacula =
committer.
>>>>=20
>>>=20
>>> Actually, yes.  Bacula is a bit tricky to configure, so your trying =
it out
>>> would be helpful if you have the time.
>>=20
>> I have been unable to test yet.  I've encountered time and hardware =
issues.
>=20
> 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.

>=20
>> I may be able to try tomorrow.
>=20
> 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!
>=20
>>>=20
>>> 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.
>>>=20
>>> You can see what I'm talking about by doing:
>>>=20
>>> mt eod
>>> mt status
>>>=20
>>> On my DDS-4 tape drive, this shows:
>>>=20
>>> # 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
>>>=20
>>> But on an LTO-5, which will give long position information, I get:
>>>=20
>>> [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
>>>=20
>>> 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:
>>>=20
>>> [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
>>>=20
>>> 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:
>>>=20
>>> Hardware End of Medium =3D yes
>>>=20
>>> 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.
>>>=20
>>>> I'll let the other Bacula devs know about this.  They deal with the =
hardware.  I work on PostgreSQL.
>>>>=20
>>>=20
>>> 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.)
>>>=20
>>> Ken
>>> --=20
>>> Kenneth Merry
>>> ken@FreeBSD.ORG
>>=20
>> ?=20
>> Dan Langille
>> http://langille.org/
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
> Ken
> --=20
> Kenneth Merry
> ken@FreeBSD.ORG

=E2=80=94=20
Dan Langille
http://langille.org/








Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36E25B53-8D76-4409-87FD-5E0369A4A513>