Re: Reducing UFS corruption from unclean shutdowns?

From: Warner Losh <imp_at_bsdimp.com>
Date: Fri, 21 Jun 2019 15:49:33 -0700
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
>
>
>
>
Received on Fri Jun 21 2019 - 20:50:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC