> On Jun 21, 2019, at 3:49 PM, Don Lewis <truck...@freebsd.org> wrote: > > On 21 Jun, Scott Long wrote: >> >>> On Jun 21, 2019, at 2:09 PM, Alan Somers <asom...@freebsd.org> wrote: >>> >>> On Fri, Jun 21, 2019 at 1:56 PM Scott Long <sco...@samsco.org> wrote: >>>> >>>> >>>> >>>>> On Jun 21, 2019, at 1:49 PM, Alan Somers <asom...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
