advfs salvage?

[lothar esser]

Hi,
we have an external Raid array with a advfs file system. When a disk broke it rebuilt itself and it seemed okay for a while. However, it started to be inaccessible out of the blue or more often when we copied files. When I checked the file system with sysman it was in a state of panic. It had worked flawlessly for too long so I did not have any experience with this error or any other for that matter. I used verify to see whether this would fix it but matters got worse.
In the /etc/fdmns/tera1_dmn we used to have dxlab_home but it was changed to dxlab_home_verify_BnIVIL and I can no longer mount the array.
advfscan could not fix it either.
"Can't open device rtera1_dmna" which is odd because it is tera1_dmn not rtera1_dmna ???

So the best I could do so far is to run salvage and got about 10-30 % of the data off the array. Of course not the data that I needed. I have restored the user accounts from a 1.5 month old tape so there is about a month worth of data on it(the array) that we need.
Is there any additional thing I could do to rebuild/repair the array ?

Thanks,

Lothar

[Rob Leadbeater]

Hi,

Without knowing what sort of external array you're using, it's difficult to say...

Can you post the output of "showfdmn tera1_dmn" and, "hwmgr view device" assuming that you're using v5.

Cheers,

Rob

[Venkatesh BL]

> "Can't open device rtera1_dmna" which is odd because it is tera1_dmn not rtera1_dmna ???

I think there is silly mistake here. Looks like the tool added 'r' for (raw device) and 'a' for partition for your input. Please check the man page and give the inputs correctly.

Also, you could try 'fixfdmn' utility. I think there is a '-n' option to check things out without making any sort of change to the disk.

[lothar esser]

Hi,

output from $ showfdmn tera1_dmn

# showfdmn tera1_dmn
showfdmn: unable to get info for domain 'tera1_dmn'
showfdmn: error = I/O error
# hwmgr view device
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/dmapi/dmapi
4: /dev/scp_scsi
5: /dev/kevm
35: /dev/disk/dsk0c COMPAQ BD0366459B bus-0-targ-0-lun-0
36: /dev/disk/cdrom0c COMPAQ CRD-8402B bus-1-targ-0-lun-0
41: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0
44: /dev/disk/dsk1c JetStor III bus-0-targ-1-lun-0
57: /dev/random
58: /dev/urandom
63: /dev/ntape/tape0 HP Ultrium 2-SCSI bus-3-targ-3-lun-0

The problem device is #44 JetStor III

L.

[Rob Leadbeater]

Hi,

I'm not familiar with the JetStor array, but things look fairly terminal.

Just to confirm, can you post the output of "ls -l /etc/fdmns/tera1_dmn"

Cheers,

Rob

[lothar esser]

Hi,

here is the output.

# ls -l /etc/fdmns/tera1_dmn/
total 8
lrwxr-xr-x 1 root system 15 May 13 2004 dsk1c@ -> /dev/disk/dsk1c*
drwxr-xr-x 2 root system 8192 Nov 14 13:22 dxlab_home_verify_BnIVIL/
#
L.

[Venkatesh BL · Accepted solution]

# ls -l /etc/fdmns/tera1_dmn/
total 8
lrwxr-xr-x 1 root system 15 May 13 2004 dsk1c@ -> /dev/disk/dsk1c*
drwxr-xr-x 2 root system 8192 Nov 14 13:22 dxlab_home_verify_BnIVIL/ <<<<
#

This is strange. This directory is used only for the device links used by the domain. Looks like some one accidentally put this directory on "Nov 14th". Can you move this directory to /tmp or some place and try the showfdmn command again?

[Rob Leadbeater]

Hi,

I also don't like the look of the @ and * symbols in the link to dsk1c.

I'd try recreating the link, after (re)moving the dxlab_home_verify_BnIVIL directory.

# cd /etc/fdmns/tera1_dmn
# ln -s /dev/disk/dsk1c

Cheers,

Rob

[Steven Schweda]

> I also don't like the look of the @ and *
> symbols in the link to dsk1c.

I don't either, which is why I don't make
"ls" an alias (or whatever) for "ls -F".

[Dennis Handly]

>Steven: which is why I don't make "ls" an alias for "ls -F".

Or when you don't want to use the alias (and using a real shell) you use: \ls