Reducing UFS corruption from unclean shutdowns?

[Don Lewis]

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.