SCO documentation regarding corrupted filesystems can be found
in Technical Article 110488.
Note: If your building has power problems, it is recommended
that you protect you data with a UPS.
First try, mounting the filesystem without any logging:
mount -v -o nolog /dev/u /u
OR in /etc/default/filesys:
Change your entry to include "mtnopts=nolog",eg.
from:
bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
fsck=yes rcfsck=yes fsckflags=-y mountflags=
to:
bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
mntopts=nolog fsck=yes rcfsck=yes fsckflags=-y mountflags=
Secondly, you can try mounting the filesystem without any
logging or checkpointing:
mount -v -o nolog,nochkpt /dev/u /u
or in /etc/default/filesys:
Add the "nochkpt" option as below:
bdev=/dev/u cdev=/dev/ru mountdir=/u rcmount=yes mount=no fstyp=HTFS
mntopts=nolog,nochkpt fsck=yes rcfsck=yes fsckflags=-y mountflags=
See mount(ADM)
If this is successful, then it is strongly recommended that the
filesystem should be backed up, before the following steps.
This attempt to recover involves using the fsdb command to truncate
the HTFS journal logfile. Running the fsck command on the filesystem
thereafter will remove the logfile and then recreate one from
scratch. If your hard disk is too damaged then it may be possible
that this method will not work.
(Note that fsdb is powerful, cryptic and unfriendly, and you can
damage your filesystem irrevocably if you are not familiar with the
details of filesystem structure. Use it with caution.)
The following steps need to be followed:
1. Shut the machine down into single user mode and ensure that
the filesystem in question is NOT mounted.
2. Run the fsdb command on the damaged filesystem:
# fsdb /dev/r<filesystem>
3. The fsdb command does not have a prompt.
Type in 4i and press enter.
4. Type in sz=0 and enter.
5. Type 4i again and press enter.
6. Type in =0100666 and enter.
7. Type in q to quit and then enter.
8. Run fsck -ofull /dev/r<filesystem>.
The fsck command will notify you that the file .slog0000 is an
incorrect file type and will seek confirmation to remove it.
Answer 'yes' to remove the file.
The fsck command will then ask you further questions as to
fixing the inode count, correcting the superblock and whether
you would like to salvage files. Answer 'yes' to
these questions.
9. Once you have run the fsck command you can then mount your
filesystem and do your own checks to ascertain the validity of
the data on the filesystem.
See fsdb(ADM)
For example :
# umount /u
# fsdb /dev/ru
/dev/ru(u): HTFS File System
FSIZE = 4217061, ISIZE = 1054272
4i
i#: 4 md: d---rwx------ ln: 2 uid: 2 gid: 2 sz: 1024
a0:131803 a1: 0 a2: 0 a3: 0 a4: 0 a5: 0 a6: 0
a7: 0 a8: 0 a9: 0 a10: 0 a11: 0 a12: 0
at: Tue Apr 3 09:21:23 2001
mt: Tue Apr 3 09:21:23 2001
ct: Tue Apr 3 09:21:23 2001
sz=0
004614.D: 000000 (0)
4i
i#: 4 md: d---rwx------ ln: 2 uid: 2 gid: 2 sz: 0
a0:131803 a1: 0 a2: 0 a3: 0 a4: 0 a5: 0 a6: 0
a7: 0 a8: 0 a9: 0 a10: 0 a11: 0 a12: 0
at: Tue Apr 3 09:21:23 2001
mt: Tue Apr 3 09:21:23 2001
ct: Tue Apr 3 09:21:23 2001
=0100666
i#: 4 md: f---rw-rw-rw- ln: 2 uid: 2 gid: 2 sz: 0
a0:131803 a1: 0 a2: 0 a3: 0 a4: 0 a5: 0 a6: 0
a7: 0 a8: 0 a9: 0 a10: 0 a11: 0 a12: 0
at: Tue Apr 3 09:21:23 2001
mt: Tue Apr 3 09:21:23 2001
ct: Tue Apr 3 09:21:23 2001
q
#
# fsck -ofull /dev/ru
/dev/ru
HTFS File System: u Volume: u
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=4
CLEAR? [yn] y
FREE INODE COUNT WRONG IN GROUP - 0
FIX? [yn] y
** Phase 2 - Check Pathnames
UNALLOCATED I=4 OWNER=root MODE=0
SIZE=0 MTIME=Jan 1 00:00 1970
NAME=/.slog0000
REMOVE? [yn] y
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=2 OWNER=root MODE=40777
SIZE=512 MTIME=Apr 3 09:21 2001 COUNT 3 SHOULD BE 2
ADJUST? [yn] y
FREE INODE COUNT WRONG IN SUPERBLOCK
FIX? [yn] y
** Phase 5 - Check Free List Bitmap
1 BLK(S) MISSING
SALVAGE? [yn] y
** Phase 6 - Salvage Free List Bitmap
3 files 513 blocks 4084761 free
*** FILE SYSTEM WAS MODIFIED ***
# mount /dev/u /u
#
NOTES:
TROUBLESHOOTING
---------------
Should you get the message "Cannot determine filesystem type" when
trying your "mount" or "fsck" then the situation is worse and the
SuperBlock table of that filesystem has become corruped. Here, running
"fsdb" would not be advisable because the tools "mount" and "fsck" are
unable to actually get onto the filesystem to examine it.
The course of action available would be to remove the filesystem,
re-create it then restore from backup.
To help determine this is the correct course of action use the
following command to determine if the filesystem's superblock is
readable:
# dtype /dev/<fs>
If this returns "unrecognised data" then the superblock is damaged or
corrupted.
If you get a valid filesystem type returned then "fsck" should have
been able to fix this.
If there is no /dev/<fs> filesystem then it's likely the device nodes
have either been deleted or the disk has been moved here from another
server. The device nodes can either be created using "mknod" or
"divvy /dev/hd[x]a". Here you would not create a new filesystem but
rather would just "install" when you "quit" from divvy to just
re-make the device nodes. NB. x = the hard disk
In either event, determine if there is data there with:
# hd /dev/<fs>
Here, it is likely you see hex data indicating that there is data on
filesystem but it can be accessed, again, indicating superblock failure
of some kind. If nothing is returned then there is no data either.
To remake the filesystems, run:
# divvy -P -N /dev/hd[x]a
NB. x = hard disk
This will give you a list of the filesystems on the active partition:
eg:
divvy -P -N /dev/hd0a
0 0 19999 boot EAFS
1 20000 115999 swap NON FS
2 116000 1961578 root HTFS
3 1961579 3923156 u HTFS
6 3923157 3923166 recover NON FS
7 0 3924080 hd0a WHOLE DISK
If "u", in this example, was to say "NON FS" then this confirms also
the SuperBlock corruption.
To recreate it, run:
# divvy /dev/hd[x]a
and "create" partition 3. There would be no need to change the Start
or End blocks but it would change the New Filesystem flag from No to
Yes and set it to HTFS.
You can then "quit" and "install" and this will a) re-create the
filesystem and SuperBlock, effectively re-formatting the filesystem and
b) will create the /dev/u and /dev/ru device nodes if they were
missing.
Use "mkdev fs" to create the mount points and entry in
/etc/default/filesys if this were required.
You should then be able to mount the filesystem and restore your data.
See Also
Technical Article 110488, "My filesystem is corrupt even after running fsck. What can
I do before restoring from backup or consulting a data recovery
service?"
Technical Article 113121, "My OpenServer server has panicked with "NOTICE: growreg -
Insufficient memory to allocate 1 page - system call failed"
|