On Fri, May 19, 2000 at 06:20:44PM +0930, Greg Lehey wrote:
> I only stumbled on this thread by accident.  If you have problems
> which involve Vinum, please copy me, and I may have input.

Ok, thanks.  Wasn't at all sure vinum had anything to do with this
crash (and I still don't know if it has), so I didn't want to "Cry
Wolf"  :-)  .

> On Friday, 19 May 2000 at  7:55:37 +0200, Bernd Walter wrote:
> > 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?
> >>
> >> <snip>
> >>  - 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.

This is a scratch box used primarily for testing -current, so I
don't have anything important on it.  Which is good, 'cause as
you suspected, it *did* crash again after a while.  This time it
was, among other things, nfs-serving a buildworld from another
filesystem at the time of the crash, so I'm not too sure what
triggered it this time (I only got the trace, not any of the
messages from the panic):

db> trace
Debugger(c0245ca3) at Debugger+0x35
panic(c0253e00,c3853a40,c1259500,c3853a40,0) at panic+0x70
handle_written_inodeblock(c1259500,c3853a40) at handle_written_inodeblock+0x2b8
softdep_disk_write_complete(c3853a40) at softdep_disk_write_complete+0x6a
bufdone(c3853a40,c0264ab8,c0128558,c3853a40,c0f78400) at bufdone+0x7e
bufdonebio(c3853a40) at bufdonebio+0xe
dadone(c0f6c680,c0f78400,c073a9a0,40000200,ffffffff) at dadone+0x210
camisr(c0282290,c0264b0c,c021e4e0,40000200,c022e8f6) at camisr+0x1eb
swi_cambio(40000200,c022e8f6,c022e41f,40000200,c0ec3800) at swi_cambio+0xd
splz_swi(c073a9a0,0,10,10,10) at splz_swi+0x14
Xresume9() at Xresume9+0x2b
--- interrupt, eip = 0xc0227a96, esp = 0xc0264b54, ebp = 0 ---
default_halt() at default_halt+0x2

> I recently fixed a number of problems in RAID-5.  Can you give me
> details of the problems you've been having, and the date of the sup?
> Since this is -CURRENT, I assume that's the version of the system too.

It is - sources from ~3 days ago, so I believe I have all your latest

> As far as soft updates goes, basically it's incompatible with Vinum,
> since there's currently no way of ensuring the sequence of writes
> across a number of disks.  I'm thinking of ways of doing it, but they
> will cause significant loss in performance.  There should be no
> problems as long as there isn't a crash, of course :-)

I wasn't aware of the incompatibility issues, so all my vinum volumes
were running with SU until a few minutes ago :-)
I have turned SU off on this R5 volume now as well, but the above trace
happened, with SU turned on.

> Greg

/Niels Chr.

 Niels Christian Bank-Pedersen, NCB1-RIPE.
 Network Manager, Tele Danmark NET, IP-section.

 "Hey, are any of you guys out there actually *using* RFC 2549?"

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to