Re: Repeatable kernel panic on -CURRENT using ZFS over SATA

> Short answer - you are overstressing your very marginal hardware.
> 
> Long answer - here's how and why:
> 
> Your rig was state of the art 7+ years ago:
> 
> http://www.supermicro.com/newsroom/pressreleases/2000/press101800.cfm
> 
> Though Dell bulds to a prce point, and may have cut a few corners..
> 
> First, your power supply may not be remaining stable under startup load:
> 
> - the 6 SeaGraaates need over 200 W to spin up, about 80W to run, and 
> the ATA controllers may not be staggered-start capable.
> 
> - the other two SeaGraates and lone Fujitsu on SCSI need another 55 W or 
> so to start up and 30+W for running load, but *are* programmable for 
> delayed/staggered spin-up. Do so if you have not already...
> 
> Then try this:
> 
> Interrupt the boot. Give the rig a few minutes to spin-up, settle down, 
> cool down, stabilize. Then continue the boot.
> 


The hard drives are on an entirely separate power supply in an external 
enclosure.  Hopefully this mitigates your suggestion of the spinup power 
problem.

> 
> Other factors:
> 
> - 7+ year old el-cheapo (Adaptec) SCSI controller was marginal when 
> brand-new.
> 

We've been using this controller for years with no problems, and even 
now when the rest of the system destabilizes, it still works fine.

> - The el-cheapo Silicon Image and onboard Intel SATA OTOH are a far 
> tougher challenge. These rely very heavily on the system RAM, CPU, and 
> bus to do everything 'arrayish'.
> 
> And there is the challenge:
> 
> There are very few true 'hardware' SATA controllers made.  Most decent 
> ones are combo SATA+iSCSI, cost the very Earth, (US$ 700 UP) and are 
> rare enouhg in new channels, let alone surplus.

Hardware RAID is far outside of my organization's price range. 
Additionally we have had bad experiences in the past with our secondhand 
RAID controllers going belly-up and taking entire arrays with them (even 
though the drives themselves were fine, the metadata or whatever got 
corrupted)

I'm interested in using ZFS for the end to end checksumming and other 
neat features, and my understanding is that it always uses software when 
it is in RAIDZ.

> 
> Bottom line is that the rig you are using hasn't got the resources for 
> the massive storage you are trying to mount.
> 
> When such storage was to be found only on 'Big iron' - even the older, 
> slower Power, Alpha, MIPS or SPARC IBM/DEC/Sun 'not-so-big' iron, very 
> powerful peripheral controllers carried much of the load.
> 
> A dual Pentium III 733 MHz with only 512 MB of (quite slow) RAM, 
> marginal SCSI controller, and bottom-end resource-hungry Silicon 
> Image/Intel SATA is not even on the same *planet* as those old beasts, 
> and a big fat enclosure with a Dell logo changeth that not.
> 
> 
> FreeBSD is superbly efficient. But not quite magical.
> 
> If you want the rig to be stable, you will either have to uprade it 
> substantially, ELSE downshift the I/O to do everything at a more 
> leisurely pace.
> 

I am quite aware that we aren't going to push 70MB/sec through this guy, 
but it's a backup server.  Probably only ever going to push a few MB/sec 
through it.  But it seems unacceptable to crash even under a 2MB/s 
bandwidth-limited rsync.

> Not what you wanted to hear, I'm sure...
> 

Obviously not :)
Is it possible to ask FreeBSD to slow down I/O instead of panicing?  I 
am ok with somewhat slow performance - this machine is slated for 
replacement at some point, but we simply don't have the resources to do 
so at the moment.  If there is one specific piece of hardware that is 
causing this issue, I can look in to replacing it, but the entire thing 
will have to live a bit longer.

We have a similar machine pushing 5MB/s to a 14-drive RAID6 array on 
Linux so I know it's not impossible given the limitations we have - the 
performance is not great but we care more about the capacity than the speed.

Are there any other things I can try?
I understand this is a very suboptimal configuration, but I would like 
to try a bit harder to make it work before giving up...

Thank you very much again,
Steven Schlansker

> Bill 'hardware' Hacker



> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"