Kern Sibbald wrote:
On Thursday 17 November 2005 11:01, Julien Cigar wrote:
I think I found the problem.
I changed the scsi id of the tape drive from ID 0 to ID 6 and it *seems*
to work better (I did a full backup and no problems occured yet). I read
that apparently ID 0 and ID 1 should not be used for tape drives (it's
for booting devices only ...)
Interesting! I'm pleased to hear that you solved the problem, and it only
goes to show how complicated hardware can be at times ...
The SCSI IDs, in order of priority, are: 07,06, ..., 00, 15, 14,...,
08, where 07 is the highest. Think of it as interrupt levels in a
real-time OS, which is pretty much what it is. The controller itself
should be the highest priority device so that it always responds to
commands. Tape drives should be on high priority IDs so that commands
to the tape drives are not queued for too long, else the device driver
will see it as a SCSI timeout error. It all depends on what the device
driver does when a SCSI command times out. For block random access
devices, sd can easily just retry the command some number of times. The
st driver has the problem that it is not always so easy to just retry a
command to a streaming device, so perhaps it is not as forgiving as the
sd driver. Easier to avoid problems by putting the streaming devices at
the higher priority IDs and random access devices at the lower.
Kern Sibbald wrote:
On Monday 07 November 2005 15:15, Julien Cigar wrote:
You think I can ignore the problem ?
When I list media you can see that the tape Weekly-0003 has not been
filled up completely (it was the tape with write errors ...)
Well, that answers the question I had: the drive could not recover from
the error, and it *did* notify Bacula. In principle, Bacula stopped
writing when the tape/drive got the error, so your backup should be good,
but personally, I would be very worried whether the data on the tape was
readable or not.
At a minimum, I would start doing Verifys of all my tape jobs to ensure
that the tape can be read -- they are slow, but at least you will know.
I would also try doing a btape "fill" on the tape that got the errors
(after ensuring that all the files are backed up elsewhere). If it fails,
I would trash the tape.
The best solution is to get a DLT or SDLT drive.
If you cannot, one thing that I noticed here with my HP drive is that
tapes from some manufacturers fail all the time, and tapes from others
last two years before failing (under heavy use). For example, if I
remember right, I have no problem with Sony tapes in my drive, but
Imation tapes cause me problems (or vise-versa). I forget because I only
use the drive for testing, and I frequently need to throw out tapes. The
only way you can know is to try tapes from different manufacturers in
your drive, and the only thing I can say for sure, is that for my drive,
there is a lot of difference between tapes from different manufacturers.
*list media
Pool: WeeklyFullBackupPool
+---------+-------------+-----------+-------------+----------+-----------
-- -+---------+------+-----------+-----------+---------------------+
| MediaId | VolumeName | VolStatus | VolBytes | VolFiles |
VolRetention | Recycle | Slot | InChanger | MediaType |
LastWritten |
+---------+-------------+-----------+-------------+----------+-----------
-- -+---------+------+-----------+-----------+---------------------+
| 1 | Weekly-0001 | Full | 71563809646 | 73 |
2592000 | 1 | 0 | 0 | DAT | 2005-10-28
10:38:32 |
| 2 | Weekly-0002 | Full | 79126531739 | 79 |
2592000 | 1 | 0 | 0 | DAT | 2005-10-30
11:28:16 |
| 3 | Weekly-0003 | Full | 45914843881 | 47 |
2592000 | 1 | 0 | 0 | DAT | 2005-11-07
06:01:46 |
| 4 | Weekly-0004 | Full | 81241762264 | 81 |
2592000 | 1 | 0 | 0 | DAT | 2005-11-07
12:17:00 |
However, the jobs terminate with a "Backup OK" termination ... strange
Kern Sibbald wrote:
On Monday 07 November 2005 09:04, Julien Cigar wrote:
Hello,
I writed a mail some weeks ago for a problem with my Sony drive (write
errors).
The drive is a Sony SDX-500C on a Adaptec 2940 Ultra SCSI.
Someone told me to upgrade the bios of the drive, which I did. It
worked fine for a week, but now I'm still having writing error
messages :
Nov 7 06:01:46 localhost kernel: st0: Error with sense data: <6>st0:
Current: sense key: Medium Error
Nov 7 06:01:46 localhost kernel: Additional sense: Write append
error Nov 7 06:01:46 localhost kernel: Info fld=0xfc00
Nov 7 06:01:46 localhost kernel: st0: Error with sense data: <6>st0:
Current: sense key: Medium Error
Nov 7 06:01:46 localhost kernel: Additional sense: Write append
error Nov 7 06:01:46 localhost kernel: Info fld=0x1
Nov 7 08:42:26 localhost kernel: st0: Error with sense data: <6>st0:
Current: sense key: Unit Attention
Nov 7 08:42:26 localhost kernel: Additional sense: Not ready to
ready change, medium may have changed
Nov 7 08:47:37 localhost kernel: st0: MTSETDRVBUFFER only allowed for
root.
What happens is, it backs up perfectly fine for a while backup,
restoring from tape works too! Then all of a sudden it starts giving an
error ...
I don't think it's tape related, the tapes are new and the problem
occurs only randomly ...
I've checked the cable too
Any idea welcomed ...
All the errors at 06:01 appear to me to be typical write errors that one
often gets on DDS tapes. From what I see, the drive recovered and
continued. I doubt that Bacula was even aware of the problem -- though
you can check in the Job report.
The errors are 8:42 are a bit worrysome. I would attempt to correlate
them with what Bacula was doing. It may only be that Bacula asked for
a new tape and tried to read while there was nothing in the drive, or
it may be some real failure.
The "error" at 8:47 is apparently after you restarted the FD. It
attempts to set the tape to variable tape format, and your kernel
forbids the request (ioctl) if the SD is not being run as root. This
can be ignored if your tape drive mode is set properly before starting
the SD.
----------
Here's the output of /proc/scsi/scsi :
phoenix:/home/jcigar# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: SONY Model: SDX-500C Rev: 0204
Type: Sequential-Access ANSI SCSI revision: 02
----------
Here's the output of /proc/scsi/aic7xxx/0 :
phoenix:/home/jcigar# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 6.2.36
Adaptec 2940 Ultra SCSI adapter
aic7880: Ultra Wide Channel A, SCSI Id=0, 16/253 SCBs
Allocated SCBs: 4, SG List Length: 128
Serial EEPROM:
0x0238 0x0238 0x0238 0x0238 0x0238 0x0238 0x0238 0x0238
0x0238 0x0238 0x0238 0x0238 0x0238 0x0238 0x0238 0x0238
0x18b6 0x005d 0x2800 0x0010 0xff00 0xffff 0xffff 0xffff
0xffff 0xffff 0xffff 0xffff 0xffff 0xffff 0x00ff 0x6499
Target 0 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 1 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Goal: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
Curr: 40.000MB/s transfers (20.000MHz, offset 8, 16bit)
Channel A Target 1 Lun 0 Settings
Commands Queued 3051621
Commands Active 0
Command Openings 1
Max Tagged Openings 0
Device Queue Frozen Count 0
Target 2 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 3 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 4 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 5 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 6 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 7 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 8 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 9 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 10 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 11 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 12 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 13 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 14 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
Target 15 Negotiation Settings
User: 20.000MB/s transfers (10.000MHz, offset 127, 16bit)
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your
very own Sony(tm)PSP. Click here to play:
http://sourceforge.net/geronimo.php
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
