logical volume write errors

[Denver Osborn]

'lssf /dev/dsk/c6t13d0' should show the "???" for the hardware path. Meaning the disk is no longer seen at that path. Rebooting the box did nothing more that remove it from ioscan because the box didn't see the scsi disk when it booted up.

I'm assuming this failed disk is an HASS (jamaica) enclosure? Can you give more detail about where the disk is at? Do you have a replacement for it or?? If you have hp h/w support for the box/disk, call in for assistance and get the failed drive replaced.

-denver

[Shaamil]

Hi all
I have reseated my disk, rebooted the server and it came up....Hoooraaa

Thanks for all your vaulble input. it is greatly appreciated. I must say the response on these forums is the best on the plannet.

Cheers all.

[Gerhard Roets]

Hi Shaamil

Just so you know, it might be degenerative disc failure this implies that the disc might fail again.

I would run mstm against that physical disk if I were you.

HTH
Gerhard

[D Block 2]

I notice BAD-Block replacement is ON, and also notice no mirror of vg04 for "acct"..

in the disk h/w there is a pool of available blocks that are reserved for BAD block re-vectoring.. if this pool runs out, you are trouble..

I would start thinking of disk replacement asap: Ignite the system to tape, if you have not do so yet. Try to set up disk mirroring, if no done yet. do you have alternate boot device ?

[Shaamil]

Hi Guys
I did the following:

I removed the disk. I do not have a replacement. I exported the vg and imported it without specifying that disk.
Now I now I will lose data, but that is fine.
I can restore what I need, but I want to try something. My LV /dev/vg04/acct looks like this....
pnp100:#/> lvdisplay -v /dev/vg04/acct | more
--- Logical volumes ---
LV Name /dev/vg04/acct
VG Name /dev/vg04
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 40000
Current LE 5000
Allocated PE 5000
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c4t1d0 1084 1084
/dev/dsk/c4t3d0 1084 1084
/dev/dsk/c4t4d0 392 392
/dev/dsk/c6t10d0 692 692
/dev/dsk/c6t11d0 967 967
/dev/dsk/c5t2d0 3 3

--- Logical extents ---
LE PV1 PE1 Status 1
0000 /dev/dsk/c6t10d0 0392 current
0001 /dev/dsk/c6t10d0 0393 current

Futher down it looks like this....

4215 /dev/dsk/c4t4d0 0388 current
4216 /dev/dsk/c4t4d0 0389 current
4217 /dev/dsk/c4t4d0 0390 current
4218 /dev/dsk/c4t4d0 0391 current
4219 /dev/dsk/c5t2d0 0122 current
4220 /dev/dsk/c5t2d0 0123 current
4221 /dev/dsk/c5t2d0 0124 current
4222 ??? 0000 current
4223 ??? 0001 current
4224 ??? 0002 current
4225 ??? 0003 current
4226 ??? 0004 current
4227 ??? 0005 current
4228 ??? 0006 current

Is there a way get rid of all the LE's from 4222 down.
Please help, suggest, anything....

[Gerhard Roets]

Hi Shaamil

In your situation of not having a replacement disk. I would personally recreate the whole vg.

Fixing it would be a "big hack" and you have already influenced a file system negatively. Rebuilding it would be the safer route to go, you do not know what other problems might crop up down the road if you maybe "hack" it a bit to much.

But just so that you know ... the symptoms you are seeing there is typical of vxfs metadata corruption. There can be a few causes.

1. Disk gone over to the dark side for some or other reason ( Your case )
2. JFS version mismatch ... moving disks from a JFS 3.5 based system down to a JFS 3.3 based syste.
3. Bad FSCK strategies, fsck can break a disks metadata if you do not follow the rules.
4. ... some other I have personally not seen yet. I am sure a lot of people would be able to add extra reasons.

HTH
Gerhard