Re: vi -r crash, netbsd-9 amd64

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 15 Oct 2022 15:38:14 +1100
    From:        Paul Ripke <stix%stix.id.au@localhost>
    Message-ID:  <Y0o5NlKH3sTZ1b0f@slave.private>

  | 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.

I'm not sure that crashes are necessarily the cause of corrupted vi
recovery files - it is possible that some sequence of editing mods is
what makes bad ones.   In any case, occasional corrupt recovery files
have been a vi "feature" for as long as recovery files have existed.

It would be nice to see this fixed, but as no-one really knows what
causes it, so no-one is able to make it happen at will, finding the
cause is not an easy task.


  | I must admit I haven't experienced this - and I either crash my system
  | or suffer accidental power loss every month or so.

You're running 9.3_STABLE right?   I'm running HEAD.  There is very
likely a difference there.   I also have quite a lot of (unused mostly)
RAM which can hold a lot of buffers, which rarely ever actually require
flushing in normal operations of my system.

  | The last corruption I saw was back in Aug 2019:

Note that the corruption I meant was fine content corruption,
the kind you refer to here:

  | https://mail-index.netbsd.org/current-users/2019/08/19/msg036431.html

is meta-data corruption is far more rare (lots of work has gone
into making sure that doesn't happen, as if it does, and isn't corrected,
things just get worse and worse).   On the other hand a file with corrupted
data inside is simply a file with corrupted data inside, and only affects
users of that file.

  | I have postgres and mongodb running, but they both do the right thing
  | with fsync, etc,

None of the files I referred to would have been subject to any kind of
sync.   Certainly not fsync, but no general sync either (I have now taken
to running a
	while sleep N; do sync; done
loop, where I pick N more or less at random after each reboot - more or
less replicating what the old update program used to do.)

kre