I was talking about the cache on the disks, not on the controller.  The issues
you experienced were due to the OpenBSD driver not marking the i4 as broken.
The workaround code is now in tree implying that only 1 IO can be outstanding
and bioctl will no longer function.  So update to the latest -stable or
-current and besides some slower performance the system should be stable and
useful.

I tried to fix this before but I haven't been able to determine what causes
these issues.  I will give this another go at some point.

On Sat, Jan 07, 2006 at 10:35:25AM +0100, Pailloncy Jean-Gerard wrote:
> >Yes, ide vs scsi benchmarks are usually skewed due to caching.   
> >SCSI disables
> >drive cache by default whereas IDE enables it by default.
> Yes, I disable caching. So I get (really) bad performance.
> 
> I see the other thread about some broken MegaRaid i4.
> 
> What I can say is taht with 3.8-release, I have no problem to use  
> bioctl.
> # bioctl -i ami0
> Volume  Status     Size           Device
> ami0 0 Online       249998344192 sd0     RAID1
>       0 Online       249998344192 0:0.0   noencl <Maxtor  
> 4A250J0          RAMB>
>       1 Online       249998344192 2:1.0   noencl <Maxtor  
> 4A250J0          RAMB>
> ami0 1 Online       249998344192 sd1     RAID1
>       0 Online       249998344192 3:0.0   noencl <Maxtor  
> 4A250J0          RAMB>
>       1 Online       249998344192 1:1.0   noencl <Maxtor  
> 4A250J0          RAMB>
> ami0 2 Degraded     499996688384 sd2     RAID5
>       0 Online       249998344192 3:1.0   noencl <Maxtor  
> 4A250J0          RAMB>
>       1 Rebuild      249998344192 1:0.0   noencl <Maxtor  
> 4A250J0          RAMB>
>       2 Online       249998344192 2:0.0   noencl <Maxtor  
> 4A250J0          RAMB>
> ami0 3 Hot spare    249998344192 0:1.0   noencl <Maxtor  
> 4A250J0          RAMB>
> 
> I broke the RAID-5 and it starts rebuilding.
> I can setup new Hot-Spare.
> 
> 
> But nothing was perfect, I had two crashes. I do not have ps and  
> trace because I was using "ddb.panic=0" to reboot the prod server  
> automatically. The crash happens when I was on console, I disable  
> "ddb.panic=1", but "luckily" I get no other crash. And I can not do  
> postmortem analysis because /var is to small to keep coredump in /var/ 
> crash. I did not have test current. I do not want to stop this server  
> too long.
> 
> So, here is the partial crash report (the dmesg is in one of my other  
> mails in this thread). I hope it will be partially useful ;-)
> 
> fsync failed: type VDIR, usecount 0, writecount 0, holdcount 1, flags  
> (VBIOONFREELIST|VBIOONSYNCLIST)
>         tag VT_UFS, ino 6987542, on dev 0, 9 flags 0x0, effnlink 2,  
> nlink 2
>         mode 040755, owner 1000, group 1000, size 512 not locked
> mounted on: /mnt
> panic: sched_sync: fsync failed
> Starting stack trace...
> panic(d057fa84,d7c73960,ea077f5c,d7c73960,d7c73960) at panic+0x71
> panic(d04f9970,d1b8b29c,d7d078f8,d17b4620,4) at panic+0x71
> sched_sync(d7d078f8) at sched_sync+0x17a
> Bad frame pointer: 0xd06f1ed8
> End of stack trace.
> syncing disks... 250 250 248 244 230 212 199 181 164 150 135 124 112  
> 108 102 89 69 45 23 1 giving up
> rebooting...
> 
> fsync failed: type VDIR, usecount 0, writecount 0, holdcount 1, flags  
> (VBIOONFREELIST|VBIOONSYNCLIST)
>         tag VT_UFS, ino 7011086, on dev 0, 9 flags 0x0, effnlink 2,  
> nlink 2
>         mode 040755, owner 1000, group 1000, size 512 not locked
> mounted on: /mnt
> panic: sched_sync: fsync failed
> Starting stack trace...
> panic(d057fa84,d7c53e60,ea077f5c,d7c53e60,d7c53e60) at panic+0x71
> panic(d04f9970,d18eda9c,d7d078f8,d17b467c,4) at panic+0x71
> sched_sync(d7d078f8) at sched_sync+0x17a
> Bad frame pointer: 0xd06f1ed8
> End of stack trace.
> syncing disks... 320 320 318 318 318 318 318 318 314 311 303 293 285  
> 280 269 254 240 233 230 221 giving up
> sd2: WARNING: cache synchronization failed
> rebooting...
> 
> Cordialement,
> Jean-Girard Pailloncy

Reply via email to