Date: Fri, 21 Jun 2019 15:51:46 -0600 From: Scott Long <scottl@samsco.org> To: Don Lewis <truckman@FreeBSD.org> Cc: Alan Somers <asomers@freebsd.org>, Chuck Silvers <chs@netflix.com>, Kirk McKusick <mckusick@mckusick.com>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: Reducing UFS corruption from unclean shutdowns? Message-ID: <D7FC707D-B863-47F2-9580-C07881AAC866@samsco.org> In-Reply-To: <tkrat.bc0479d0867a8175@FreeBSD.org> References: <CAOtMX2jPut4ve-Tr7DyikxXqnmqycyjEUpNmAiwUSXbQrK3iCA@mail.gmail.com> <C3016BDF-4B51-4A59-94F2-CCBD0DC4562E@samsco.org> <CAOtMX2jXiaOWpVdEg3_nBYinJWd=iwN_38hQ4eMOocgs8dMWhQ@mail.gmail.com> <F93827F6-1B99-4BDD-B245-C9594AD28ED7@samsco.org> <tkrat.bc0479d0867a8175@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 21, 2019, at 3:49 PM, Don Lewis <truckman@FreeBSD.org> wrote: > > On 21 Jun, Scott Long wrote: >> >>> On Jun 21, 2019, at 2:09 PM, Alan Somers <asomers@freebsd.org> wrote: >>> >>> On Fri, Jun 21, 2019 at 1:56 PM Scott Long <scottl@samsco.org> wrote: >>>> >>>> >>>> >>>>> On Jun 21, 2019, at 1:49 PM, Alan Somers <asomers@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D7FC707D-B863-47F2-9580-C07881AAC866>