Missing data ina a file system

[Raul del Castillo_1]

There were a file system in my workstation defined in this way, in fstab:

/dev/vg01/lvol24 /users/oracle vxfs rw,suid,delaylog,datainlog 0 2

But its current ( and wrong) asignation is:
castillo@sevhh056> bdf /users/oracle
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 86016 28673 54011 35% /

Notice the new volume group asignation to /users/oracle. All the oracle information is missing ( 3,5Gb) and I do not understandt it.
How cab I reassign the /dev/vg01/lvol24 to /users/oracle? I think , in this way I could reciver all the data.

[spex]

Raul,

/dev/vg00/lvol3 was probably already mounted at /users/oracle when you made changes to fstab. Changes to fstab don't take effect until you reboot or until you re-mount all filesystems (e.g. 'mount -a'). However, if /dev/vg00/lvol3 was mounted at /users/oracle at the time you attempted to re-mount, you would be unable to mount /dev/vg01/lvol24. You would first have to 'umount /dev/v/g00/lvol3'.

It's hard to say if you will be successful in recovering your data. You will certainly improve your chances by ensuring that Oracle is offline before unmounting lvol3 and mounting lvol24.

PCS

[Mancboy]

Hi Raul,
you haven't actually mounted /users/oracle.
the bdf shows that /users/oracle is currently not a filesystem
but is only a directory in root (/)

So please try mount /users/oracle and post the output. It could be that /users/oracle requires an fsck before it will mount.

You can also try the following command "lvdisplay /dev/vg01/lvol24" which will tell you that this LV still exists.

[Raul del Castillo_1]

Ohh, looking carefully at the syslog.log file I can see this entry:
Jan 15 19:01:03 sevhh056 vmunix: SCSI: unrecoverred deferred error (dev = 0x1f025000, lba = 0x0)
Jan 15 19:01:03 sevhh056 vmunix:
Jan 15 19:01:03 sevhh056 vmunix: SCSI: Async write error -- dev: b 31 0x025000, errno: 5, resid: 8192,
Jan 15 19:01:03 sevhh056 vmunix: blkno: 2026024, sectno: 4052048, offset: 2074648576, bcount: 8192.
Jan 15 19:01:03 sevhh056 vmunix: vxfs: mesg 055: vx_metaioerr - /dev/vg01/lvol24 file system meta data write error
Jan 15 19:01:03 sevhh056 vmunix: vxfs: mesg 017: vx_ilisterr - /users/oracle file system inode 2756 marked bad
Jan 15 19:01:03 sevhh056 vmunix: vxfs: mesg 015: vx_ilisterr - /users/oracle file system can't mark inode 2756 bad
Jan 15 19:01:03 sevhh056 vmunix: vxfs: mesg 031: vx_disable - /dev/vg01/lvol24 file system disabled
Jan 15 22:59:56 sevhh056 syslog: su : + tty?? root-oracle
Jan 15 23:01:04 sevhh056 vmunix: vxfs: mesg 055: vx_metaioerr - /dev/vg01/lvol1 file system meta data read error
Jan 15 23:01:04 sevhh056 vmunix: vxfs: mesg 008: vx_direrr - /depot file system inode 2 block 1445 error 5
Jan 15 23:01:04 sevhh056 vmunix: vxfs: mesg 008: vx_direrr - /depot file system inode 2 block 1445 error 5

And volume group vg001 it is dissapear, must I suppose that it is broken?

[Fabian Briseño]

Hello Raul.
looks like your hardware is damaged. contact your HP support center.

maybe it's patch related or firmware related but you better place a call just to be sure.

[Mancboy]

Hi Raul,
looks like it could well be a disc problem.

To see what LVs are defined in vg01, run the following "vgdisplay -v vg01"
this will tell you which LVs are in this VG and also which PVs (discs).

If you get "volume group not activated" then run "vgchange -a y vg01" then retry the vgdisplay command.

To check the filesystem for errors, run "fsck -F vxfs -n -p -o full,nolog", this will check but not actually do anything (the -n bit).

I'd make a dd backup of the device first before running a proper fsck of it. If you have the option, then it would be best to mirror the disc before touching it.
To do this, you will need a second hard disc (I assume your workstation only has two internal discs, so you'd need to do this via the external SCSI port).
To mirror:
1) ioscan -funC disc
2) insf
3) pvcreate (the new disc)
4) vgextend vg01 (the new disc)
5) lvextend -M 1 lvol24 (the new disc)

You can then unplug your faulty disc and fsck the new one (or vgreduce vg01 (the faulty disc) to take this fauly disc out of the VG)