Reducing UFS corruption from unclean shutdowns?

[Scott Long]

> 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