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