Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Mar 2015 17:03:53 -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:  <4FD3E56B-2B55-4C1F-95C2-58366EAD1180@langille.org>
In-Reply-To: <20150302214240.GA91133@mithlond.kdm.org>
References:  <20150302003150.GB71528@mithlond.kdm.org> <D1C8E304-6DE7-4A03-A350-64E097EC4804@langille.org> <20150302022957.GB73433@mithlond.kdm.org> <0F17CDDB-4CE9-4881-B948-6B9BEDEB6455@langille.org> <20150302163146.GA85515@mithlond.kdm.org> <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org> <20150302172846.GB87055@mithlond.kdm.org> <12EED94D-CC9D-44C4-91C2-62C8A51B839B@langille.org> <B310DE3F-42D8-4093-98D3-009D887C47DB@langille.org> <95BCE742-8CC4-41FC-9FDD-D12C7A337951@langille.org> <20150302214240.GA91133@mithlond.kdm.org>

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

> On Mar 2, 2015, at 4:42 PM, Kenneth D. Merry <ken@FreeBSD.ORG> wrote:
>=20
> On Mon, Mar 02, 2015 at 16:34:34 -0500, Dan Langille wrote:
>>=20
>>> On Mar 2, 2015, at 2:47 PM, Dan Langille <dan@langille.org> wrote:
>>>=20
>>>=20
>>>> On Mar 2, 2015, at 2:07 PM, Dan Langille <dan@langille.org> wrote:
>>>>=20
>>>>=20
>>>>> On Mar 2, 2015, at 12:28 PM, Kenneth D. Merry <ken@FreeBSD.ORG> =
wrote:
>>>>>=20
>>>>> On Mon, Mar 02, 2015 at 11:44:09 -0500, Dan Langille wrote:
>>>>>>=20
>>>>>>> On Mar 2, 2015, at 11:31 AM, Kenneth D. Merry <ken@FreeBSD.ORG> =
wrote:
>>>>>>>=20
>>>>>>> On Mon, Mar 02, 2015 at 11:09:57 -0500, Dan Langille wrote:
>>>>>>>>=20
>>>>>>>>> On Mar 1, 2015, at 9:29 PM, Kenneth D. Merry <ken@FreeBSD.ORG> =
wrote:
>>>>>>>>>=20
>>>>>>>>> On Sun, Mar 01, 2015 at 19:41:07 -0500, Dan Langille wrote:
>>>>>>>>>>=20
>>>>>>>>>>> On Mar 1, 2015, at 7:31 PM, Kenneth D. Merry =
<ken@FreeBSD.ORG> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> On Sun, Mar 01, 2015 at 19:15:05 -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
>>>>>>>>>>>>> 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 have this in /usr/local/etc/bacula/bacula-sd.conf
>>>>>>>>>>>>=20
>>>>>>>>>>>> Device {
>>>>>>>>>>>> Name                    =3D DLT
>>>>>>>>>>>> Description             =3D "QUANTUM DLT7000 1624"
>>>>>>>>>>>> Media Type              =3D DLT
>>>>>>>>>>>> Archive Device          =3D /dev/nsa1
>>>>>>>>>>>>=20
>>>>>>>>>>>> Autochanger             =3D YES
>>>>>>>>>>>> Drive Index             =3D 0
>>>>>>>>>>>>=20
>>>>>>>>>>>> Offline On Unmount      =3D no
>>>>>>>>>>>> Hardware End of Medium  =3D yes
>>>>>>>>>>>> BSF at EOM              =3D yes
>>>>>>>>>>>> Backward Space Record   =3D no
>>>>>>>>>>>> Fast Forward Space File =3D no
>>>>>>>>>>>> TWO EOF                 =3D yes
>>>>>>>>>>>> }
>>>>>>>>>>>>=20
>>>>>>>>>>>> FYI, http://www.freebsddiary.org/digital-tl891.php (from =
2006) has a btape test on this same model.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Here's the test I ran tonight:
>>>>>>>>>>>>=20
>>>>>>>>>>>> [root@cuppy:/usr/home/dan] # btape -c =
/usr/local/etc/bacula/bacula-sd.conf /dev/nsa1                           =
                                                                    =20
>>>>>>>>>>>> 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
>>>>>>>>>>>>=20
>>>>>>>>>>>> =3D=3D=3D Write, rewind, and re-read test =3D=3D=3D
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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.
>>>>>>>>>>>>=20
>>>>>>>>>>>> This is an *essential* feature ...
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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.
>>>>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read =
test =3D=3D=3D
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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.
>>>>>>>>>>>> =3D=3D=3D Test Succeeded. End Write, rewind, and re-read =
test =3D=3D=3D
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> =3D=3D=3D Append files test =3D=3D=3D
>>>>>>>>>>>>=20
>>>>>>>>>>>> This test is essential to Bacula.
>>>>>>>>>>>>=20
>>>>>>>>>>>> I'm going to write one record  in file 0,
>>>>>>>>>>>>             two records in file 1,
>>>>>>>>>>>>       and three records in file 2
>>>>>>>>>>>>=20
>>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>>=20
>>>>>>>>>>>> btape: btape.c:622-0 tape_dev.c:345 ioctl MTIOCGET error on =
"DLT" (/dev/nsa1). ERR=3DNo error: 0.
>>>>>>>>>>>> We should be in file 3. I am at file 0. This is NOT =
correct!!!!
>>>>>>>>>>>>=20
>>>>>>>>>>>> Append test failed. Attempting again.
>>>>>>>>>>>> Setting "Hardware End of Medium =3D no
>>>>>>>>>>>> and "Fast Forward Space File =3D no
>>>>>>>>>>>> and retrying append test.
>>>>>>>>>>>=20
>>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> 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.)
>>>>>>>>>=20
>>>>>>>>> Issue a READ POSITION with the short form specified:
>>>>>>>>>=20
>>>>>>>>> camcontrol cmd sa1 -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - |hd
>>>>>>>>>=20
>>>>>>>>> Issue a READ POSITION with the vendor-specific block numbers:
>>>>>>>>>=20
>>>>>>>>> camcontrol cmd sa1 -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - |hd
>>>>>>>>>=20
>>>>>>>>> Issue a READ POSITION with the long form data:
>>>>>>>>>=20
>>>>>>>>> camcontrol cmd sa1 -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> Sadly, no:
>>>>>>>>=20
>>>>>>>> [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=20
>>>>>>>> (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:~] #=20
>>>>>>>=20
>>>>>>> Okay.  Not too surprising I suppose.
>>>>=20
>>>>=20
>>>> Does this mean much to you?
>>>>=20
>>>> 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
>>>>=20
>>>>=20
>>>> I'm having trouble with labeling barcodes from Bacula and the above =
is seen in /var/log/messages
>>>=20
>>> The barcodes issue is resolved.  I changed to using drive 0 instead =
of drive 1, now that we have both drives.
>>>=20
>>> *label barcodes slots=3D3,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
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>  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=3D64512 DVD=3D0 Volume=3D"FAI261" =
Device=3D"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=3D64512 DVD=3D0 Volume=3D"FAI262" =
Device=3D"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       |             |
>>> =
+---------+------------+-----------+---------+----------+----------+------=
--------+---------+------+-----------+-----------+-------------+
>>> *
>>>=20
>>> But this is what arrives in /var/log/messages during the above:
>>>=20
>>> 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
>>>=20
>>> Anything to be concerned about?
>>=20
>> When adding a 2nd job to a tape:
>>=20
>> 02-Mar 21:29 cuppy-sd JobId 19: Error: Unable to position to end of =
data on tape device "DTL03" (/dev/nsa0): ERR=3Dtape_dev.c:345 ioctl =
MTIOCGET error on "DTL03" (/dev/nsa0). ERR=3DNo error: 0.
>>=20
>> I've gotten this on three consecutive tapes.  NOTE: These *are* tapes =
I no longer use because of higher rates of corrected errors.
>>=20
>> The problem seems to be locating the end of the data.
>=20
> Do you have 'Hardware End of Medium  =3D no' in the configuration =
file?
>=20
> In looking at the code, it may be set to yes, and that could be the =
issue
> here.

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

>> 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.
>>=20
>=20
> I would expect that on these particular tape drives because they don't
> support long position information.

Ahh, good.
=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?4FD3E56B-2B55-4C1F-95C2-58366EAD1180>