Re: Reducing UFS corruption from unclean shutdowns?

On Fri, Jun 21, 2019 at 3:51 PM Scott Long <scottl_at_samsco.org> wrote:
>
>
>
> > On Jun 21, 2019, at 3:49 PM, Don Lewis <truckman_at_FreeBSD.org> wrote:
> >
> > On 21 Jun, Scott Long wrote:
> >>
> >>> On Jun 21, 2019, at 2:09 PM, Alan Somers <asomers_at_freebsd.org> wrote:
> >>>
> >>> On Fri, Jun 21, 2019 at 1:56 PM Scott Long <scottl_at_samsco.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On Jun 21, 2019, at 1:49 PM, Alan Somers <asomers_at_freebsd.org> wrote:
> >>>>>
> >>>>> I panic my development VM regularly.  Each time, I need to fsck the
> >>>>> file system.  Even if I had run sync(8) just before the panic, I
> >>>>> frequently find corruption.  What should I change to make sync(8)
> >>>>> work, or at least to make corruption rare?  It looks like my root file
> >>>>> system is using soft-updates+journal.  Should I disable those?
> >>>>>
> >>>>
> >>>> What corruption do you regularly see?
> >>>>
> >>>> Scott
> >>>
> >>> fsck reports various types of errors, all repairable, like "INODE
> >>> CHECK-HASH FAILED", "FREE BLK COUNT(S) WRONG IN SUPERBLK", "SUMMARY
> >>> INFORMATION BAD", "BLK(S) MISSING IN BIT MAPS", and "UNREF FILE".  If
> >>> I don't run fsck, then I get errors when I try to access files.  Like
> >>> "inode XXX: check-hash failed" and "such and such is marked as an
> >>> executable file but could not be run by the operating system".
> >>> -Alan
> >>
> >> The freeblk count and summary information messages are normal and expected.  I
> >> don’t think that the blks missing message is expected, and the unref file message is
> >> definitely a red flag of something that should have been handed with journal
> >> recovery.  Kirk and Chuck, do you have any insight here?
> >
> > Blks missing is to be expected.  The free block bitmap isn't updated
> > until after the pointers to them in the inode are cleared.  Likewise the
> > unref file warning is also to be expected because the reference to the
> > inode in the parent directory is cleared before the inode is cleared.
> > These aren't a fatal problem, just a resource leak until fsck is run.
> >
> > I would not expect the inode check-hash error.  I would expect the hash
> > update to happen at the same time as any other bits of the inode are
> > changed, but this is a new feature that went in after I last looked at
> > the code.
> >
>
> I thought that unref’d files were also supposed to be cleaned up on journal recovery,
> different from plain SU recovery/preening.  It’s been so long, maybe I don’t remember
> correctly anymore.
>
> Scott

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