Date: Tue, 03 Sep 1996 02:03:47 +0200 From: Torbjorn Granlund <tege@matematik.su.se> To: questions@freebsd.org Subject: Disk corruption problems (desperation!) Message-ID: <199609030003.CAA23190@insanus.matematik.su.se>
next in thread | raw e-mail | index | archive | help
Just two weeks ago, I swapped disks and got a new Ultra SCSI controller.
The new disk is a 4.4GB Fujitsu 2954SAU, and the controller is an Adaptec
2940UW. At the same time, I upgraded from FreeBSD 2.1 to 2.1.5.
During installation, the FreeBSD installtion program complained that the
disk label (of the pristine SCSI disk) was bad, and gave me the option to
procdeed or to modify it. I chose to modify it, giving what I though were
the correct parameters. From the output of `disklabel sd0' one might
conclude that the disklabel is wrong:
quiet> disklabel -r sd0
# /dev/rsd0c:
type: SCSI
disk: sd1s1
label:
flags:
bytes/sector: 512
sectors/track: 1
tracks/cylinder: 1
sectors/cylinder: 1
cylinders: 1
sectors/unit: 8498506
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 131072 0 4.2BSD 0 0 0 # (Cyl. 0 - 131071)
b: 282624 131072 swap # (Cyl. 131072 - 413695)
c: 8498506 0 unused 0 0 # (Cyl. 0 - 8498505)
e: 131072 413696 4.2BSD 0 0 0 # (Cyl. 413696 - 544767)
f: 6348800 544768 4.2BSD 0 0 0 # (Cyl. 544768 - 6893567)
g: 1604938 6893568 4.2BSD 0 0 0 # (Cyl. 6893568 - 8498505)
Note the wild cylinder numbers!
Today, my 3.1 GB /usr file system started to act weird. When doing `ls -l'
in a directory, I got "Bad file descriptor" for one of the directories.
When running fsck, it said "/foo/bar/foobar unallocated, delete?". fsck
complained like that about a large number of files. I also got a large
number of unref files and files with incorrect counts.
A curious facts is that all the problematic files had inode numbers around
253600 or 491900.
Does this information give any hint on what might be wrong? Is the bogus
disklabel the culprit? Isn't the geometry simply used for scheduling of
disk accesses? The total number of sectors and thereby the disk size seems
to be correct.
I used to keep my partitions below 2GB, to avoid potential problems with
integer overflow in the kernel. This time I decided to try with a larger
file system. Could the file system size be the culprit?
I am desperate to get my system going again. Now, I don't dare to modify
any files, and that makes it somewhat hard to do useful work...
(Fortunately, I have a fairly recent backup.)
Torbjorn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609030003.CAA23190>