Thanks to Andy McCammot and Mike Salehi. Andy drudged up a SUN FAQ that
basically said if fsck doesn't work you're hosed. I was hosed.
Luckily I didn't have to restore from tape, but I did need to newfs a 100gb
volume (not speedy). The oracle dba's export to a volume twice a week and
I back up that directory the same day. They had done an export 2 nights
before the crash and the exports were still available (different volume) so
they just imported them. Our data doesn't change all that often so it was
fine.
I am learning to dislike VM raid-5 tremendously. I wasn't logging so that
was part of the problem but, after all, parity is still written to disk
right? Shouldn't be that hard, or unstable. Working on a non-raid5
solution.
Thanks,
~JK
---------------------- Forwarded by Jeff Kennedy/NDS on 11/09/2000 09:42 AM
---------------------------
"Jeff Kennedy" <jeff.kennedy@natdecsys.com> on 11/05/99 09:44:31 AM
To: sun-managers@sunmanagers.ececs.uc.edu
cc: (bcc: Jeff Kennedy/NDS)
Subject: Urgent! - Mangled inode entry
I have a raid 5 volume under VM 2.5 on an E3500 with Solaris 2.6. Last
night I lost a disk, SUN came out to replace it. After the new disk was
replaced the volume never tried to sync, it showed active and enabled.
This morning when someone tried to access a database on this volume I got
the following entry in /var/adm/messages:
NOTICE: /u05: bad dir ino 1920 at offset 40: mangled entry
NOTICE: /u05: bad dir ino 1920 at offset 0: mangled entry
The directory name (oradata) under this volume is inode 1920 and there's
nothing in it (there should be about 50 gb's). 'du' on /u05 shows nothing
in this directory but 'df' still shows that volume having 65 gb's of data
in it (which would be correct).
Is there a way to fix this? SUN support is telling me I may be hosed and
have to restore, which would not be fun and make running raid pointless.
Thanks,
~JK
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:32 CDT