Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Mar 2015 11:44:09 -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:  <85E2DDA0-4A2B-4316-A318-3706B3A05C11@langille.org>
In-Reply-To: <20150302163146.GA85515@mithlond.kdm.org>
References:  <20150214003232.GA63990@mithlond.kdm.org> <7CA52DF3-E073-4F50-BE4E-01C51CCDF2C7@langille.org> <20150217183645.GA30947@mithlond.kdm.org> <303C48AC-0DA8-447C-8DE7-0A1DD5DD7351@langille.org> <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>

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

> 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
>> The SDLT server is on 9.3 though:
>>=20
>> [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     =
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
>> [root@knew:/usr/home/dan] #=20
>>=20
>>=20
>> It took me a while to figure that out... there is no sa1 on *this* =
system.
>>=20
>> But, my SDLT:
>>=20
>> [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] #=20
>=20
> Just to confirm, can you send the output of:
>=20
> camcontrol inquiry sa0 -v
>=20
> 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@knew:~] $ sudo camcontrol inquiry sa0 -v
pass10: <COMPAQ SuperDLT1 5F5F> Removable Sequential Access SCSI-2 =
device=20
pass10: Serial Number CXB46H0716 =20
pass10: 80.000MB/s transfers (40.000MHz, offset 31, 16bit)
[dan@knew:~] $=20

>=20
>>>=20
>>> 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.
>>>=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: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!
>>>>>>=20
>>>>>> Now the important part, I am going to attempt to append to the =
tape.
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> 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=3D4, blocks=3D7, bytes =3D 451,136
>>>>>> End scanning the tape.
>>>>>> We should be in file 4. I am at file 4. This is correct!
>>>>>>=20
>>>>>>=20
>>>>>> It looks like the test worked this time, please add:
>>>>>>=20
>>>>>>  Hardware End of Medium =3D No
>>>>>>=20
>>>>>>  Fast Forward Space File =3D No
>>>>>> to your Device resource in the Storage conf file.
>>>>>>=20
>>>>>> The above Bacula scan should have output identical to what =
follows.
>>>>>> Please double check it ...
>>>>>> =3D=3D=3D Sample correct output =3D=3D=3D
>>>>>> 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=3D4, blocks=3D7, bytes =3D 451,136
>>>>>> =3D=3D=3D End sample correct output =3D=3D=3D
>>>>>>=20
>>>>>> 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=20
>>>>>> the tape.
>>>>>>=20
>>>>>> Skipping read backwards test because BSR turned off.
>>>>>>=20
>>>>>>=20
>>>>>> =3D=3D=3D Forward space files test =3D=3D=3D
>>>>>>=20
>>>>>> This test is essential to Bacula.
>>>>>>=20
>>>>>> I'm going to write five files then test forward spacing
>>>>>>=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: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!
>>>>>>=20
>>>>>> 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!
>>>>>>=20
>>>>>> =3D=3D=3D End Forward space files test =3D=3D=3D
>>>>>>=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Do you wish to continue with the Autochanger test? (y/n): y
>>>>>>=20
>>>>>>=20
>>>>>> =3D=3D=3D Autochanger test =3D=3D=3D
>>>>>>=20
>>>>>> 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)
>>>>>>=20
>>>>>> The test autochanger worked!!
>>>>>=20
>>>>> Great, thanks for running the test!  Looks like things are working =
as well
>>>>> as they were before.
>>>>>=20
>>>>>>>=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
>>>>>> Errors are interesting to me.  Especially corrected errors. They =
are a good indicator of tape quality.
>>>>>>=20
>>>>>=20
>>>>> 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'.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> But you can certainly take a look at it and have an idea of =
whether your
>>>>> particular tape/drive are experiencing issues.
>>>>=20
>>>> That's a lot of output: =
https://gist.github.com/dlangille/0e15a7fbf7acab56fd32
>>>=20
>>> That is a lot.
>>>=20
>>>> I will run some Bacula jobs soon.  I'm still setting up config =
files.
>>>=20
>>> Thanks for all the testing, I really appreciate it!
>>>=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?85E2DDA0-4A2B-4316-A318-3706B3A05C11>