[2828] in linux-scsi channel archive
Re: Massive corruption
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Tue Nov 18 17:03:19 1997
Date: Tue, 18 Nov 1997 22:58:08 +0100 (MET)
From: Gerard Roudier <groudier@club-internet.fr>
To: Justin Miller <jhm@umr.edu>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <199711180150.TAA13036@rocket.cc.umr.edu>
On Mon, 17 Nov 1997, Justin Miller wrote:
> Hello again,
>
> I am using the fireport 40 scsi controller, using a patched
> 2.0.29, with the 2.5d driver for ncr cards. Recently an ext2 partion and
> two vfat partitions have become corrupt on my ultra-wide drive. This is
> a listing of my devices
> Host: scsi0 Channel: 00 Id: 01 Lun: 00
> Vendor: SEAGATE Model: ST43400N Rev: 1028
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 03 Lun: 00
> Vendor: MICROP Model: 4743WS Rev: S162
> Type: Direct-Access ANSI SCSI revision: 02
> Host: scsi0 Channel: 00 Id: 04 Lun: 00
> Vendor: HP Model: CD-Writer 6020 Rev: 1.07
> Type: CD-ROM ANSI SCSI revision: 02
>
> the old seagate hard drive has never caused me any trouble, but the
> micropolis is the one with filesystem corruption. When I started putting
> data together on my hd, for burning a cd this morning I noticed that a
> couple of scripts that I ususally
> use, weren't working, my /usr/local was a link to my ext2 partition on
> the micropolis drive, and it showed nothing when i did an ls. I decided
> to unmount it and do an e2fsck, e2fsck gave me a bunch of errors, I cant'
> remember what the errors were but after 93 of them e2fsck gave up trying
> to check the fs. This has happened before, using a different controler,
> and last time I wasn't sure what had caused it, since the partition was
> empty I just reformatted it with mke2fs, and it had been working fine
> until this morning.
> I decide to check my vfat partitions, when I did an ls on them, a lot of
> weird characters werer spit on the screen, and the hard drive started
> grinding really badly. I decided it was probably wise to reboot, and see
> what this would do to windows. Windows showed the dos partitions as
> being just fine, except for some stuff that I had written to the hard
> drive under linux, scandisk claimed that there "were errors", and was not
> very specific as to what those errors were.
> I pulled the hd out, and checked the jumper settings on the drive, and
> noticed that the jumper for parity was not shorted. Apparently I had
I donnot have information about your drive settings capability, but I
would think that the default setting corresponding to 'no jumper'
should be rather 'scsi parity checking enabled' than the opposite.
> forget to set that one. I put set the jumper, put the drive back in and
> booted into linux, fdisk now says:
> Warning: ignoring extra data in partition table 5
> Warning: ignoring extra data in partition table 5
> Warning: ignoring extra data in partition table 5
> Warning: invalid flag c2b9 of partition table 5 will be corrected by w(rite)
>
> Command (m for help): p
>
> Disk /dev/sdb: 131 heads, 63 sectors, 1017 cylinders
> Units = cylinders of 8253 * 512 bytes
Such a geometry has probably been guessed by scsicam_bios_param().
Has this drive been used the first time under linux with a NCR53C8XX?
If not, which OS and SCSI controller has been used with it?
> Device Boot Begin Start End Blocks Id System
> /dev/sdb1 * 1 1 187 771624 83 Linux native
> /dev/sdb2 188 188 1017 3424995 5 Extended
> /dev/sdb5 ? 375880 376901 470796387457826 3 XENIX usr
>
>
> sdb5,6,7 were each 1.1 gigs, now they seem to have dissappeared.
>
> I have idea on what to do now, I can't get e2fsck to do anything now it
> just says this even if I use a different superblock :
> e2fsck 1.04, 16-May-96 for EXT2 FS 0.5b, 95/08/09
> e2fsck: Bad magic number in super-block while trying to open /dev/sdb
I would think you just attempted to fsck the entire disk, but since I
never tried such a thing I'm not sure at all.
> The filesystem superblock is corrupt. Try running e2fsck with an alternate
> superblock using the -b option. (8193 is commonly an alternate superblock;
> Hence, 'e2fsck -b 8193 <device>' may recover the filesystem.)
If some other OS is running fine with some partition, could you
check what geometry is actually used by this OS for your drive?
Gerard.
