On Wed, Oct 12, 2022 at 07:46:10PM +0700, Robert Elz wrote: > Date: Wed, 12 Oct 2022 22:57:00 +1100 > From: Paul Ripke <[email protected]> > Message-ID: <[email protected]> > > | "vi -r", etc, and it seemed to work fine. The recovery file that causes > the > | crash was left behind after a kernel panic. > > The recovery file will be corrupted. I have seen that kind of thing > from time to time - vi -r really shouldn't crash when it attempts to > recover the mangled file, but it really doesn't matter, nothing is likely > to ever recover it, vi core dumping is just its weird way of telling you > that.
Interestingly, the file was last updated about 10 days before the crash... and I do see fsync calls from vi on the recno recovery file, too. > The bigger issue is that we have an issue with file system flushing, on > panic, everything is normally supposed to be written, but that can't be > guaranteed ... a bigger issue is that we aren't flushing file data > almost ever. A while ago, I had a power failure (no chance for the > kernel to flush anything before the system died - so no surprise there > were corrupted files). What was a surprise was that files that had > last been touched 12 hours previously hadn't been updated. That's not > really acceptable. I must admit I haven't experienced this - and I either crash my system or suffer accidental power loss every month or so. The last corruption I saw was back in Aug 2019: https://mail-index.netbsd.org/current-users/2019/08/19/msg036431.html I have postgres and mongodb running, but they both do the right thing with fsync, etc, and am yet to see corruption with them. I also did power-off style testing with qmu a file back and couldn't duplicate corruption. -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
