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.Received on Fri Jun 21 2019 - 19:49:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:21 UTC