Hello All,
Thanks for the answers, I have gotten multiple good solutions here. Yes
Indeed I have not provided some key details, well the OpenBSD 5.2 boxes
were running in Vmware Server 2.X free until they were migrated to
Vmware Workstation 8,9 and finally to Workstation 12 boxes.
HDD was set to IDE since that is what Vmware recommends for OpenBSD.
The crashes and filesystem corruptions never been OpenBSD's fault but
outside circumstances (power outages, vm servers run out of memory froze
the vms, disk DMA errors caused whole VMM to hang until reboot etc).
I have now successfully tested OpenBSD6.0's auto recovery in Vmware 12.0
by copying bunch of small files from other machine through ftp and
pulling the plug (killing the VMX pid), at start it always fixed all the
errors so upgrading to 6.0 will be the solution I choose.
Good to see the clean and precise system engineering work which went
into OpenBSD, hopefully it will never get corrupted by System(d) and
alikes, in the future I should migrate even more servers to OpenBSD.
On 2016-11-28 12:36, Stuart Henderson wrote:
On 2016-11-24, Peter N. M. Hansteen <pe...@bsdly.net> wrote:
As far as I can remember, OpenBSD does indeed run a file system check
at
boot if there are indications that the system did not shut down
cleanly.
I don't think the system has changed very much in that respect at all
for a very long time.
Correct. But /etc/rc uses fsck -p which only allows minor repairs
automatically and requires intervention for major repairs (which are
more likely to lose data).
On simple remote firewall boxes (where failing to boot is as big a
problem
as a toasted filesystem) I modify this.
Next, look into what caused those file systems to go bad in the first
place.
Yes, very much this.
