Hello:

I've got an Overland ARCvault12 w/single LTO-2 drive.  SCSI
controller is an LSI using mpt driver (wh/seems to be a pos and not
something i'd user again).  btape "test" and "fill" complete but when I
run successive backups the tape never changes - same result w/both
mtx-changer and rc-chio-changer.  Both scripts work correctly
from command line.

Results from the ARCVault web mangement interface, mt, and tapeinfo:

# camcontrol devlist -v
scbus0 on mpt0 bus 0:
<HP Ultrium 2-SCSI S33H>           at scbus0 target 1 lun 0 (sa0,pass0)
<OVERLAND ARCvault 0221>           at scbus0 target 1 lun 1 (pass1,ch0)
<  >                               at scbus0 target -1 lun -1 ()
scbus1 on mpt0 bus 1:
<  >                               at scbus1 target -1 lun -1 ()
scbus-1 on xpt0 bus 0:
<  >                               at scbus-1 target -1 lun -1 (xpt0)

# camcontrol inquiry ch0     
pass1: <OVERLAND ARCvault 0221> Removable Changer SCSI-3 device 
pass1: Serial Number 2B71000099
pass1: 160.000MB/s transfers (80.000MHz, offset 64, 16bit)

 
# camcontrol inquiry sa0
pass0: <HP Ultrium 2-SCSI S33H> Removable Sequential Access SCSI-3
device pass0: Serial Number HU10642DJ0
pass0: 160.000MB/s transfers (80.000MHz, offset 64, 16bit)


An example from rc-chio-changer:

# ./rc-chio-changer /dev/ch0 list
1:NNE440L2
3:NNE442L2
4:NNE443L2
5:NNE444L2
6:NNE445L2
7:NNE446L2
8:NNE447L2
9:NNE448L2
10:NNE449L2
11:NNE450L2
12:NNE451L2

# mt status
Mode      Density              Blocksize      bpi      Compression
Current:  0x42                 variable       0        0x1
---------available modes---------
0:        0x42                 variable       0        0x1
1:        0x42                 variable       0        0x1
2:        0x42                 variable       0        0x1
3:        0x42                 variable       0        0x1
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0  Record Number: 12       Residual Count 0

I'm not sure precisely what 0x42 density mode is since mt man page omits
it...

# mt geteotmodel
/dev/nsa0: the model is 2 filemarks at EOT

So this means I need "TWO EOF = Yes", correct?


# /usr/local/sbin/tapeinfo -f /dev/pass0
Product Type: Tape Drive
Vendor ID: 'HP      '
Product ID: 'Ultrium 2-SCSI  '
Revision: 'S33H'
Attached Changer: No
SerialNumber: 'HU10642DJ0'
MinBlock:1
MaxBlock:16777215
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x42
BlockSize: 0
DataCompEnabled: yes
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 12


# /usr/local/sbin/tapeinfo -f /dev/pass1
Product Type: Medium Changer
Vendor ID: 'OVERLAND'
Product ID: 'ARCvault        '
Revision: '0221'
Attached Changer: No
SerialNumber: '2B71000099'
Ready: yes

So above would indicate the hardware compression is turned on, wh/is
also consistent with the ARCVault web interface reports:

Detailed Drive 1 Status
Cleaning Status OK
Hardware Compression    On
Drive Temperature       44�C
SCSI ID 1
SCSI LUN        0
Write-Protected No
Media Source    Slot 9
Remaining Capacity      200 GB
Read Compression Ratio  Unknown until after read/write
Write Compression Ratio Unknown until after read/write

However, btape fill only writes 200GB before switching tapes and from
above "Remaining Capacity" of blank tape is 200GB (w/hw compression
turned on I would expect 400GB).  But maybe this just reports native
capacity.  But if hw compression is enabled, as reported by web mgmnt,
mt, and tapeinfo, then why does btape fill only write 200BG?

I do get this during btape fill:

8-Jul 01:40 btape: End of Volume "TestVolume1" at 295:14049 on device
"Drive-1" (/dev/nsa0). Write of 64512 bytes got 0. 08-Jul 01:40 btape:
btape Error: Re-read last block at EOT failed. ERR=block.c:1006 Read
zero bytes at 295:0 on device "Drive-1" (/dev/nsa0). btape:
btape.c:2343 Last block at: 295:14048 this_dev_block_num=14049

before proceeding to complete test:

The first block on the second tape matches.

Reposition from 0:2 to 0:11
Reading block 11.

The last block on the second tape matches. Test succeeded.

But I think this is because of "Backward Space Record  = No" in my
sd.conf:

Autochanger {
  Name = Autochanger
  Device = Drive-1
  Changer Command = "/usr/local/etc/bacula/rc-chio-changer %c %o %S %a %
d" Changer Device = /dev/ch0
}
 
Device {
  Name = Drive-1                      #
  Drive Index = 0
  Device Type = Tape
  Media Type = LTO-2
  Archive Device = /dev/nsa0
  AutomaticMount = yes;               # when device opened, read it
  AlwaysOpen = yes;
  RemovableMedia = yes;
  RandomAccess = no;
  AutoChanger = yes
  Alert Command = "sh -c 'smartctl -d scsi -H -l error %a'"
# fbsd stuff:
    TWO EOF = Yes;
    Hardware End of Medium = No;
    Fast Forward Space File = No;
    BSF at EOM = Yes;
    Backward Space Record  = No;
}

So I am baffled as to where to go from here?

Hmm.. I just checked smarctl:

# smartctl -a /dev/nsa0
smartctl version 5.37 [i386-portbld-freebsd6.2] Copyright (C) 2002-6
Bruce Allen Home page is http://smartmontools.sourceforge.net/

Device: HP       Ultrium 2-SCSI   Version: S33H
(pass0:mpt0:0:1:0): MODE SENSE(06). CDB: 1a 0 1c 0 40 0 
(pass0:mpt0:0:1:0): CAM Status: SCSI Status Error
(pass0:mpt0:0:1:0): SCSI Status: Check Condition
(pass0:mpt0:0:1:0): UNIT ATTENTION asc:28,0
(pass0:mpt0:0:1:0): Not ready to ready change, medium may have changed
Serial number: HU10642DJ0
Device type: tape
Transport protocol: Parallel SCSI (SPI-4)
Local Time is: Sun Jul  8 15:20:33 2007 EDT
TapeAlert Supported
TapeAlert: OK

Current Drive Temperature:     44 C
Drive Trip Temperature:        255 C

Error counter log:
           Errors Corrected by           Total   Correction
Gigabytes    Total ECC          rereads/    errors   algorithm
processed    uncorrected fast | delayed   rewrites  corrected
invocations   [10^9 bytes]  errors read:          0        0
0         0          0          0.000           0 write:
0        0         0         0          0          0.000           0


I wonder wtf is up with that?  I've run that same check before and not
gotten the error..  I'm going to run a camcontrol reset and play with
this some more.  In the meantime any help appreciated.

oh yeah,one more thing; I can run an mt erase 0" w/o error but a full
erase "mt erase" yields bunches of this in the logs:

Jul  7 17:00:00 hamlet kernel: mpt0: attempting to abort req
0xc4fac4f0:11612 function 0 Jul  7 17:00:00 hamlet kernel: mpt0: abort
of req 0xc4fac4f0:11612 completed Jul  7 17:00:00 hamlet kernel: mpt0:
attempting to abort req 0xc4fac4f0:11612 function 0 Jul  7 17:00:00
hamlet kernel: mpt0: abort of req 0xc4fac4f0:11612 completed

TIA-

-- 
Best regards,

Ken Gunderson
GPG Key -- 9F5179FD

"Never hold discussions with the monkey when the organ grinder is in
the room." - Sir Winston Churchill

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to