On Fri, May 19, 2000 at 06:24:39AM +0200, Niels Chr. Bank-Pedersen wrote:
> On Fri, May 19, 2000 at 12:01:59AM +0200, Bernd Walter wrote:
> > On Thu, May 18, 2000 at 11:43:58PM +0200, Niels Chr. Bank-Pedersen wrote:
> > > On Thu, May 18, 2000 at 11:21:51PM +0200, Bernd Walter wrote:
> > > > Does vinum list saying that one subdisk of your R5 volume is down?
> > >
> > > 5 subdisks:
> > > S raid5.p0.s0 State: up PO: 0 B Size: 4133 MB
> > > S raid5.p0.s1 State: up PO: 768 kB Size: 4133 MB
> > > S raid5.p0.s2 State: up PO: 1536 kB Size: 4133 MB
> > > S raid5.p0.s3 State: up PO: 2304 kB Size: 4133 MB
> > > S raid5.p0.s4 State: up PO: 3072 kB Size: 4133 MB
> > >
> > > - But since my first attempt to initialize the plex crashed the
> > > box while only da5se1 was missing, I did a "verify media" from
> > > the SCSI ctrl. BIOS, and did find errors. They were all successfully
> > > remapped, though.
> >
> > I thought about a parity corrpution bug that there was in history.
> > But as all drives are up and they are freshly initialized there are 2
> > arguments why your problems should be different.
> > Maybe one drive crashed and the system paniced before vinum was able to update
> > the state database on the drives.
> > Did you saw anything unusual on the console before the panic message?
>
> It seems to be a hardware problem with da5. After the latest
> crash, I had the following in dmesg:
>
> (da5:ahc4:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
> (da5:ahc4:0:2:0): NO SENSE
That's harmless - it only means that your drive doesn't understood the
sync-cache command which is to flush the drives write-cache to the media.
If there wasn't anything else then there's no reason to beleave that something
went wrong with one of your drives.
> - after obliterating the vinum configuration I created the volume
> without da5, and I have now successfully copied 250+MB to the filesystem.
>
> I would have thought that hardware errors like this could be handled
> in a slightly more controlled manner, though.
At this moment there is no sign of a hardware error.
The panic itself means that the filessytem allocated a block which already was
allocated. Usually it means that the data on the drive got corrupted while
mounted.
You should be carefully testing the volume before copying important data to it.
In my expirience I can say that using softupdates stresses the I/O system much
more than the standard way so it makes sense to test with softupdates.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
