Reducing UFS corruption from unclean shutdowns?

[Alan Somers]

On Fri, Jun 21, 2019 at 4:50 PM Warner Losh <imp at bsdimp.com> wrote:
>
>
>
> On Fri, Jun 21, 2019, 3:44 PM Scott Long <scottl at samsco.org> wrote:
>>
>>
>>
>> > On Jun 21, 2019, at 4:37 PM, Warner Losh <imp at bsdimp.com> wrote:
>> >
>> > On Fri, Jun 21, 2019, 3:33 PM Conrad Meyer <cem at freebsd.org> wrote:
>> >
>> >> On Fri, Jun 21, 2019 at 2:55 PM Alan Somers <asomers at freebsd.org> wrote:
>> >>> I would've thought that immediately following a sync(8), the
>> >>> filesystem would be consistent.  Why do I still see errors after a
>> >>> panic in files that were written before I sync()ed?
>> >>> -Alan
>> >>
>> >> Hi Alan,
>> >>
>> >> Contra the name, sync(2) (sync(8)) isn't synchronous.  It invokes
>> >> VFS_SYNC() with MNT_NOWAIT across all mountpoints.
>> >>
>> >
>> > Yes. Sync(2) just starts the I/O, but it may be delayed if there is a lot
>> > of dirty buffers. The other issue is that new buffers may be dirtied…
>> >
>>
>> Still, the point of SU and SU+J is that the filesystem should not be
>> damaged and require active repair on reboot, whether or not a
>> sync or fsync was done.  There’s certainly issues with disk lying
>> about out of order writes, POSIX sematics of unlinked files, and the
>> inherent design of UFS superblock updates, but the problems that
>> Alan reported should still be looked at, they’re not expected and
>> they undermine the usefulness of SU+J.
>
>
> Yea. Ata write cache might cause it. But only once in a while and usually only with power fail. Some drives / devices need a final flush, so that might be an issue. I fixed an issue in nvme on shutdown like this, but panic should trigger that code...
>
> Warner

No ATA write cache here.  I'm using bhyve with a virtio disk.