fsck and dump freeze freebsd. any ideas?

[Edward Sanford Sutton, III]

  After one of the last crashes, the system would lock up a short time after 
rebooting. I found the problem caused by background fsck locking up the 
system. I took the partition out of the startup check for now. I 'think' I 
was installing a port during the last crash, but it has been a while.
  I performed a fsck and a dump (to /dev/null) confirming that both do crash 
the freebsd 7.2 and 6.2 (which I booted off of a separate drive). A tar 
to /dev/null did run successfully, but I recall reading that that is not a 
recommended way to backup/move a filesystem. The /usr partition where it 
causes trouble is in a raid5 geom_vinum three drive array. I did not yet have 
the array rebuild the parity nor do I know if there is any 
advantage/disadvantage in doing so (for this problem). I ran a long test on 
the drives using smartctl (which is a safer surface check than dd because 1 
bad sector on my promise controller will cause a panic; I have an unrelated 
drive with a corrupted sector if the promise controller dirver has an 
interested maintainer.)
  When running fsck, it is somewhere within phase 1 when it crashes. I ran a 
truss run of fsck with -aedD and snapped a photo of my screen when it crashed 
which I can type up if it is of any use. At the time of freebsd freezing, the 
hard drive activity light goes from a faint flicker to on solid for about a 
second and then goes out. The system is completely unresponsive where it 
locks showing no sign of activity that I have been able to notice.
  I imagine the recommendation is start over, but before I do (and likely just 
try a tar backup/restore), are there any other suggestions and questions 
before I blow away the problem? It would be nice for freebsd users to not be 
able to run into such a problem.
  As a final question, is there any safe way to crash freebsd (or pull system 
power) without a risk of filesystem corruption?