On Tue, 20 Feb 2018 12:39:53 +0100 <gljennjohn_at_gmail.com> said > On Mon, 19 Feb 2018 14:18:15 -0800 > "Chris H" <bsd-lists_at_BSDforge.com> wrote: > > > I'm seeing a number of messages like the following: > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d > > > > and was wondering if it's anything to be concerned with, or whether > > fsck(8) is fixing them. > > This began to happen when the power went out on a new install: > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST > > 2017 > > root_at_dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64 > > which hadn't yet been hooked up to the UPS. > > I performed an fsck in single user mode upon power-up. Which ended with the > > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL. > > I answered Y. > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly: > > newfs -U -j > > > > Thank you for all your time, and consideration. > > > > fsck fixes these errors only when the user does NOT use the journal. > You should re-do the fsck. This doesn't seem quite right. That is; fsck(8) /should/ fix it when soft journaling is enabled. Otherwise the -j option, to newfs(8) and journaling have no value. OTOH you are indeed correct in that "falling through" will correct any errors. I used that option after submitting this question. But there /does/ appear to be a regression. As this has never been the case in earlier versions of FreeBSD. fe; imposing the same conditions on an 11, or 9.3 system does NOT exhibit this problem. I literally pulled the plug on 2 systems (1 _at_11, and 1 _at_9.3) and fsck(8) using the journal happily fixed the errors, without any latter fallout as described in this message. Thank you very much Gary, for taking the time to reply! --Chris > > -- > Gary JennejohnReceived on Wed Feb 21 2018 - 01:27:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC