FreeBSD is too filesystem errors sensitive

[cronfy]

>> Please forgive me for probably a very stupid question. But why is 
>> FreeBSD so sensitive to filesystem errors that it ends up with panics 
>> like 'freeing free block' or 'ffs_valloc: dup alloc'? I just can't 
>> get it. Failed to allocate vnode? Go allocate another one! Freeing 
>> free block? Leave it free then! I understand these situations should 
>> never happen, but the hell why is it required to panic and kill 
>> everything that would be working happily even if something very 
>> disasterous happen to /backup partition, in example?
> Probably because UFS is not designed to be a backup file system but a 
> working one :)
>
> All those errors indicate file system corruption. To protect other 
> data from getting corrupted (e.g. by invalid pointers or 
> calculations), the kernel panics.

To protect us against terrorists our government do strange things too ;-)

After panic data *is* getting corrupted anyway - MySQL tables that were 
open are broken, soft-updates are unsync'ed etc etc.
 Server is required to reboot, fsck, time is wasted while this occurs. 
Why all this should happen because of a single vnode fail? Why not just 
throw message in /var/log/messages, return "oh, I failed to save a file" 
to the process that initiated the operation and just go on? Are 
consequences of attept to "free already free block" *so* dangerous that 
it is needed to give up on EVERYTHING? Let's say it was not /backup 
partition, ok, it was /var/tmp/some-php-session or even 
/var/cron/tabs/someuser file that failed. So what? Even 
/boot/kernel/kernel corruption is not critical if you are not going to 
reboot right now (or if you have /boot/kernel.old :)

Is there a way to say "Dear kernel, don't panic, I'am holding your hand, 
keep working please-please-please?" If so, can it lead to complete 
filesystem corruption indeed or it is not so serious?

Thanks.