Re: vi -r crash, netbsd-9 amd64

[Paul Ripke <stix%stix.id.au@localhost>]

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 <stix%stix.id.au@localhost>
>     Message-ID:  <Y0arjLwawGcfkohI@slave.private>
> 
>   | "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.