Date: Fri, 24 Sep 2004 17:42:53 -0400 From: "Webster, Andrew" <awebster@connectalk.com> To: <freebsd-fs@freebsd.org>, <freebsd-questions@freebsd.org> Subject: Help/problems with fsck_ffs Message-ID: <9D61D69E3C1F7F459C5513AD830EE219047E7B@mtlex01.connectalk.com>
next in thread | raw e-mail | index | archive | help
FreeBSD: 5.2.1-RELEASE, and 5.2.1-p10
=20
Synopsis
I have 2 identical systems with very large 1.3TB disk array (OS sees it
as a single drive /dev/da1)
On one system fsck /dev/da1s1d works fine, on the other fsck /dev/da1s1d
fails with BAD SUPER BLOCK error.
=20
Description
On the problem system, fsck returns:
# fsck_ffs /dev/da1s1d
** /dev/da1s1d
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
ALTERNATE
=20
LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y
=20
64 is not a file system superblock
917118848 is not a file system superblock
1834237632 is not a file system superblock
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).
=20
However when running fsck_ffs -b 192 (192 because newfs listed it as a
backup superblock location) /dev/da1s1d on the problem system, it works
fine.=20
# fsck_ffs -b 192 /dev/da1s1d
Alternate super block location: 192
** /dev/da1s1d
** Last Mounted on=20
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
298602 files, 10861179 used, 309521859 free (763 frags, 38690137 blocks,
0.0% fragmentation)
=20
UPDATE STANDARD SUPERBLOCK? [yn] y
=20
=20
***** FILE SYSTEM WAS MODIFIED *****=20
=20
Trying fsck_ffs /dev/da1s1d again after responding to UPDATE STANDARD
SUPERBLOCK still returns BAD SUPER BLOCK error message, so the update
isn't happening, or it is writing to THE WRONG PART OF THE DISK!
=20
I recompiled fsck_ffs with debugging and spent a while looking at it,
and have a few observations.
=20
Setup.c 346: super *=3D dev_bsize;
Interestingly this doesn't work as expected when debugging. Super went
from 128 to 128 as I stepped through this code (dev_bsize was 512). I
don't know if it is a problem with GDB or with GCC, but when I removed
the -O option in the compile, it worked, and super went from 128 to
65536, but didn't fix the superblock problem.
=20
Second observation: Setup.c 356
getblk(&asblk, cgsblock(&sblock, sblock.fs_ncg - 1),
sblock.fs_sbsize);
This looks like to goes to get the _LAST_ superblock on the drive and
then compares it to the first. If they don't match: error.
The problem is that there is no way to _correct_ a particular
superblock, as the UPDATE STANDARD SUPERBLOCK only fixes the first one
if there is a problem with it. The only way to workaround the problem
is to backup the data, newfs and restore, but 1.3TB is somewhat large...
=20
The question: How to you repair the damaged superblock when it isn't
the first one?
=20
--
Andrew=20
=20
*************************************************************************=
*************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager=
or the=20
sender immediately and do not disclose the contents to anyone or make cop=
ies.
** eSafe scanned this email for viruses, vandals and malicious content. *=
*
*************************************************************************=
*************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D61D69E3C1F7F459C5513AD830EE219047E7B>