SCSI device sending messages to syslog.log

[Didier Rox]

Hi all,

My HP11.00/32 servers are sending a lot of messages in the syslog.log when a disk is defective. Every 5 seconds, vmunix is recording 5 to 10 lines per bad disk. This is using a lot of CPU because some tools are filtering the syslog.log for monitoring purposes.

Is there a way to avoid having those lines produced or to increase the interval between them. 5 seconds to replace a disk is short!!!

Many Thanks,
Didier

Lines pattern is
SCSI: bp: 140ca800
dev: 1f012000
cdb: 28 00 00 00 00 10 00 00 04 00
residual: 800
status: XXXXXXXXX

[Mohanasundaram_1]

Hi ,

The messages are indicating problem while accessing the drive data. So, the messages will come as many times as the data is being retrieved.

So, if you are sure that this is a particular disk problem, arrange to replace the disk. If this is a disk having mirror copy on another disk, then remove the disk and keep.

If there is no mirror and you want to avoid the messages, then unmount filesystems available on this disk.

If you can provide the syslog.log in its entirety we can have a look at the problem.

With regards,
Mohan.

[Didier Rox]

Thanks for this quick answer.

In fact I can find the origin of the problem (power failed, removed disk, defective disk, ...). My disks are mirrored so I'm losing nothing but, unfortunately, disks are located 70 kilometers from office and systems are 24/7 ones. I can neither remove disk quickly nor unmount file system.

The problem is the frequency of the message. It's exactely 5 seconds between 2 messages even if access to the mirror disk is continuous. It's not related to the IO but maybe to a check LVM is processing at constant interval.

Do you think that interval can be modified?

Didier

[Suraj_2]

Hi

Please check the device with the device file

c1t2do

ioscan -f | grep -i c1t2do
will give the details of the device

Rgds
Suraj

[Didier Rox]

Dears,

I do not ask for the status of the disk. The problem is that I have between 400000 and 1000000 lines generated in the syslog per day.
I just want to get rid of them BEFORE they are written.

Didier

[Peter Godron]

Didier,
a possible solution would be to chnage the /etc/syslog.conf file to throw away the messages. THIS MEANS YOU COULD MISS OTHER ERRORS !!
Regards

[Jannik]

If it is mirrored you could do 2 things.

1. remove the mirror site that is causing the problem:
If MirrorDisk/UX is installed it is usually saver and faster to use mirroring as an alternative to
pvmove. In order to move lvol4 from PV c0t1d0 to c0t2d0 just mirror it to c0t2d0 and remove
the mirror from c0t1d0 afterwards:
# lvextend -m 1 /dev/vg01/lvol4 /dev/dsk/c0t2d0
# lvreduce -m 0 /dev/vg01/lvol4 /dev/dsk/c0t1d0

2. move fysical extends away from faulted disk:
In order to move all PEs of lvol4 that are located on PV c0t1d0 to PV c1t2d0:
# pvmove -n /dev/vg01/lvol4 /dev/dsk/c0t1d0 /dev/dsk/c0t2d0

I WOULD GO FOR sollution 1! and then mirror it again to a nother disk.

Take a look at this pdf:
http://www4.itrc.hp.com/service/iv/node.do?admit=-938907319+1108555579047+28353475&node=prodITRC%2FWW_Start%2FN1%7C16%7C11

[Mohanasundaram_1]

Hi Didier,


Have you removed the defective disk and still you are getting this error?

Consider Peter's suggestion. but beware of the pitfall.

If disks are within 70KM you can as well get them and replace in few hours.

Also indicate what type of storage is this. Is it an external storage unit or an internal disk?

What are the syslog.log messages after you removed the defective disk ( I am assuming you have done it already).

With regards,
Mohan.

[Florian Heigl (new acc) · Accepted solution]

If Your disks are mirrored, and one of them is broken, You ought to remove it anyway, if the server locks up for any reason You might and up with a completely corrupt box.
Also, the errors ARE IO-related, even if this is just MirrorDisk/UX trying to sync stale PE's.

Do remove the disk from the vg and have it replaced.
To lower the amount of messages You receive You can increase the physical volume timeout and set immediate_report to 0.