[Fwd: Summary; Disk Errors]

From: Hall, Johnny (johnny@pahv.xerox.com)
Date: Mon Jun 14 1999 - 14:46:33 CDT


A number of people have pointed out a brain fart on my part. The
filesystem was bigger that 2gb so you DO need to run fsck against the
raw block device /dev/rdsk/...
                  ^

I had already mounted the filesystem as read only and started tarring
stuff to a new filesystem before someone pointed this out. After it
finished I ran fsck against the raw device and it still failed, but the
point of this email is to ensure everyone knows that I should have ran
fsck on the raw device in the first place.

Thanks Again,

Johnny "Desperately Fighting Off Angry Users" Hall

Stephen Lee wrote:
>
> Johhny,
> you didn't say what size the partition was. Check this out from the man
> page.
> Good luck,
> Steve
>
> Running fsck on file systems larger than 2 Gb fails if the
> user chooses to use the block interface to the device:
>
> fsck /dev/dsk/c?t?d?s?
> rather than the raw (character special) device:
>
> fsck /dev/rdsk/c?t?d?s?
>
> "Hall, Johnny" wrote:
> >
> > [Original Question Posted Below]
> >
> > Thanks to Rich Quinn, Mark Neill, Amarjeet Virdi, and Mark Almeida.
> >
> > Rich said to try the "preen" option with fsck - no luck
> > Mark N. said to specify the fstype with fsck - no luck
> > Mark A. pointed me to vxvol and vxmend - no luck
> > Amarjeet suggested I mount it read only and move the data.
> > Though I was trying to avoid this it looks like it is my only option at
> > this time since I have 30 angry engineers stopping by my office every
> > couple of minutes. :)
> >
> > The general concensus is that there is a bad disk. I couldn't find
> > anything in /var/adm/messages about this but I did find several memory
> > errors or maybe cpu errors...
> >
> > May 31 10:32:00 raptor unix: Syndrome 0x58, Size 3, Offset 0 UPA MID
> > 5
> > May 31 10:32:00 raptor unix: Softerror: Persistent ECC Memory Error
> > May 31 10:32:00 raptor unix: Corrected SIMM Board 0 J3800
> > May 31 10:32:00 raptor unix: ECC Data Bit 31 was corrected
> > May 31 10:32:00 raptor unix: CPU5 CE Error: AFSR 0x00000000 00100000,
> > AFAR 0x00000000 6e52fa88, SIMM Board 0 J3800
> >
> > Thanks,
> >
> > Johnny
> >
> > Original Question -
> >
> > [E6500, A5000 running Veritas 2.6
> >
> > I have a filesystem (striped only) on an E6500. The machine crashed for
> > an unknown reason (nothing in /var/adm/messages) and one of the
> > filesystems is bad. When I run fsck I get this...
> >
> > root@RAPTOR>>> fsck /dev/vx/dsk/rootdg/raptor5
> > ** /dev/vx/dsk/rootdg/raptor5
> >
> > CANNOT SEEK: BLK 31449600
> > CONTINUE? y
> >
> > CANNOT READ: BLK 31449600
> > CONTINUE? y
> >
> > CANNOT SEEK: BLK 31449600
> > CONTINUE? y
> >
> > THE FOLLOWING SECTORS COULD NOT BE READ: 31449600 31449601 31449602
> > 31449603
> > root@RAPTOR>>> mount /export5
> > mount: the state of /dev/vx/dsk/rootdg/raptor5 is not okay
> > and it was attempted to be mounted read/write
> > mount: Please run fsck and try again
> >
> > I think I can somehow repair this filesystem with either format or
> > veritas but am not sure how. Can anyone help me?
> >
> > TIA
> >
> > Will summarize
> >
> > Johnny]
> > --
> > "Nothing is more difficult than the art of maneuvering for advantageous
> > positions." - Sun Tzu
>
> --
> Stephen J. Lee Saint Joseph's University
> Systems Administrator 5600 City Avenue
> Networking & Telecommunications Philadelphia, PA 19131-1395
> E-mail: lee@sju.edu Voice: (610) 660-1679
> Fax: (610) 660-1536

-- 
"Nothing is more difficult than the art of maneuvering for advantageous
positions." - Sun Tzu



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:21 CDT