Reducing UFS corruption from unclean shutdowns?

[Warner Losh]

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

Scott
>
>
>
>