OpenBSD Sync disks in a better way

[e1-531g]

News/call for testing from tech: 2017-12-01 20:48
Sync disks in a better way

Originally Posted by Theo de Raadt

For more than a decade I have pointed out vfs_shutdown does a terrible
job, but noone took the bait to fix it. It uses proc0, does spl0, and
a loop which makes it clear the operation may fail... and we've see
evidence the loop fails. It really cannot gaurantee the filesystem is
clean.

bluhm recently pointed out a problem where the failure could cause
entry into ddb (long story removed), so I rolled up my sleeves.
kettenis suggested rather than unmounting filesystems we could try
downgrading them to read-only. That exposed a deep-down copyin in
each filesystem's VOP handling function for mounts, vfs_init
infrastructure needed to some love.

After all that work, it turns out writeable vnodes on a readonly
filesystem can cause the change to readonly to fail, so we need to
invalidate such vnodes with a hammer.

This seems to be working. I'd like to know of anyone sees failures,
otherwise in few days I'll test this in snapshots. (Besides building
a new kernel, you want to make includes, build a new sysctl binary,
and install that).

[e1-531g]

FFS should become even more rock solid.

https://marc.info/?l=openbsd-tech&m=151526338730514&w=2
Subject: clean on-disk filesystems through {suspend,hibernate}/resume
From: Theo de Raadt <deraadt () openbsd ! org>

I've been working for about a month to ensure filesystems are
maximally syncronized and/or clean on-disk through a suspend/resume
cycle.

The idea is if a suspend/resume or hibernate/resume sequence gets
broken (by pulling the power+battery during suspend, or similar
circumstances during the hiberate-write sequence), we can be assured
that the filesystems are in the best shape. And if done correctly,
we'll even have marked-clean filesystems which don't need a fsck, so
that fresh boot is faster.

There is also a similar case when softraid (layers) underly the
filesystems. These layers need proper syncronization to disk also.

Previously we've been ignoring this issue, and frankly we've done
mostly fine...

The changes starts with a series of changes to suspend. It is a bit
tricky to syncronize the in-memory soft-state of the fileystems to
disk, and block new in-memory changes from happening.

New allocations of vnodes are caused to sleep-spin, so that other
processes cannot advance creating new files. All mountpoints are told
to non-lazy sync their filesystems and locks are held on these
mountpoints so that no new activity can occur. During this phase, the
number of dangling inodes (nlink == 0) is counted, and if any are
found the on-disk filesystem is marked dirty, otherwise marked clean.
Next, softraid can be told to save it's state, but it uses vnodes so a
hack allows it to bypass the sleep-spin mentioned earlier. Once the
suspend code knows there are no more tsleep, it can unwind the mount
locks so there is less to worry about upon resume.

I would appreciate reports, and later I'll cut this into pieces and
commit incremental changes.

[e1-531g]

Does anyone also see thing like:

syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up

in dmesg (memory still available after reboot)?
I don't use softdep. I use softraid-based crypto.

$ mount
/dev/sd1a on / type ffs (local, noatime)
/dev/sd1e on /usr type ffs (local, noatime, nodev, wxallowed)
/dev/sd1d on /var type ffs (local, noatime, nodev, nosuid)
mfs:8739 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=819200 512-blocks)
/dev/sd1h on /home type ffs (local, noatime, nodev, nosuid)
mfs:15369 on /var/log type mfs (asynchronous, local, nodev, nosuid, size=40960 512-blocks)
/dev/sd0f on /mnt/fat_part_windows type msdos (local, noatime, nodev, noexec, uid=1000, gid=1000)