topic Re: stale issue in Operating System - HP-UX

stale issue

emily_3 — Wed, 17 May 2006 01:04:57 GMT

Hello,

In my system's vg01 have 5 disks mirror with other 5 disks, today I found there are 3 disks are stale. They are c6t0d0, c6t2d0, c6t4d0 by lvdislay, vgdisplay.
I have tried "ioscan", "diskinfo",
"dd if=xx of=xx count=10000", but everything is ok.
I have no idea, is this disk issue? Thanks.

Re: stale issue

Mridul Shrivastava — Wed, 17 May 2006 01:10:24 GMT

How do we recognize this situation?
===================================

One way to identify the situation is to attempt to read the LV using dd as
in the following test:

T1) #dd if=/dev/vg00/lvtest of=/dev/null bs=256k &

If this command returns an I/O error, then LVM cannot provide a valid copy
of the data, which must then be restored from backup, if necessary (of
course, we would not need to restore anything if the LV is brand new or
used for swap.)

How can we avoid the situaton?
==============================

Creating a new LV and modifying procedure A such that extension to the
desired size is the *last* step will circumvent the issue:

B1) create the LV of size 0 with no disk,
B2) extend the LV with minimum size to disk1,
B3) setup the mirror by extension to the second disk2 and then
B4) extend it to the desired size.

During the extension to the desired size, LVM again creates each PE with
the flag "current" just as before; however, now this is done on *both*
disk1 and disk2. Note that procedure B avoids the time consuming step A3 to
copy data from disk1 to disk2. If another mirror were added, LVM could read
a logical extent even in the case that one of the physical extents returned
a read error.

Re: stale issue

m saravanan — Wed, 17 May 2006 01:11:07 GMT

Just try to re-sync the VG and check the status again,

# vgsync /dev/vg01

Regds,
Saravanan

Re: stale issue

Mridul Shrivastava — Wed, 17 May 2006 01:11:10 GMT

We want
to setup a new logical volume (LV) that is mirrored, i.e. each logical
extent (LE) is mapped to two physical extents (PE) on different disks. It
is common practice to follow these steps:

A1) create the LV on a single disk1,
A2) extend it to the desired size, and then
A3) setup the mirror by extension to the second disk2.

Note that in step A2, by design LVM assigns the "current" flag to each new
(and, thus, still empty) PE (on disk1 only).

In step A3 LVM copies each PE to the mirror. Depending on the LV's size,
this takes some time to complete. If the copy succeeds, the mirror PE also
gets the flag "current". If the copy fails, e.g., due to a read error on
disk1, the flag remains "stale".

Usually after procedure A, all PEs are marked "current." A read error on
disk1, however, is confusingly displayed as a stale extent on disk2. If
disk2 is replaced, then the same read error will most likely be encountered
on disk1, and the extents still will be displayed as stale on disk2.

How do we recognize this situation?
===================================

One way to identify the situation is to attempt to read the LV using dd as
in the following test:

T1) #dd if=/dev/vg00/lvtest of=/dev/null bs=256k &

If this command returns an I/O error, then LVM cannot provide a valid copy
of the data, which must then be restored from backup, if necessary (of
course, we would not need to restore anything if the LV is brand new or
used for swap.)

How can we avoid the situaton?
==============================

Creating a new LV and modifying procedure A such that extension to the
desired size is the *last* step will circumvent the issue:

B1) create the LV of size 0 with no disk,
B2) extend the LV with minimum size to disk1,
B3) setup the mirror by extension to the second disk2 and then
B4) extend it to the desired size.

During the extension to the desired size, LVM again creates each PE with
the flag "current" just as before; however, now this is done on *both*
disk1 and disk2. Note that procedure B avoids the time consuming step A3 to
copy data from disk1 to disk2. If another mirror were added, LVM could read
a logical extent even in the case that one of the physical extents returned
a read error.

Re: stale issue

emily_3 — Wed, 17 May 2006 01:26:00 GMT

Hi,

1. I have tried vgsync, lvsync all return I/O error.

2. I will create a new LVM according to the above procedure. But one question, base on my server's disk state, I will use one "current" good disk as disk1 and "stale" disk as disk2, correct?

Re: stale issue

emily_3 — Wed, 17 May 2006 01:51:08 GMT

I create a new LV at good disk first,but couldn't lvextend to stale disk anymore.

#lvextend -m 1 /dev/vg01/test /dev/dsk/c6t0d0

lvextend: Warning: couldn't query physical volume "/dev/dsk/c6t0d0":
The specified path does not correspond to physical volume attached to
this volume group

But I did "dd if=/dev/dek/c6t0d0 of=/dev/null count=10000", everything is ok.

Re: stale issue

Mridul Shrivastava — Wed, 17 May 2006 02:09:34 GMT

I guess there is some corruption of LVM header, request you to deactivate the vg using vgchange -a n vg01 command, then restore the vg conf.

vcfgrestore -n vg01 /dev/dsk/c6t0d0

execute this for all the three stale disk and then activate the vg using vgchange -a y vg01 command.
I hope it works for u this time...

Cheers

Re: stale issue

emily_3 — Wed, 17 May 2006 03:47:45 GMT

Thanks for your suggestions. I have restored the vg files, but it seems takes very long time when activing the vg01. it is still processing. Is it normal?

Re: stale issue

emily_3 — Wed, 17 May 2006 20:25:12 GMT

Hello,

The issue has been solved by restore the configuration files for the 3 harddisk. Thanks for help...