Can anyone spread the light onto kernel messages after 8.2 => 8.3 update?

J

joint

Hello to All!

Can anyone help me to spread the light onto the kernel messages posted below:

Code: 
Jul 25 09:14:12 adatahost kernel: DDEEBBUGU:G :u fusdfisrdhiarshha_schr_ecarteea tae gagaaiinn  iipp==00xxffffffffffff0022eeaa77001144d0d0 v 
pv=p=00xxffffffffff0f0f007e00278e0280000 0d hd=h=0xfffff0fx0f2f0fd4fcfffa00200 dl4ocwfmaem0c0o ulnotw=memcount=1615685 8co ucnot=un0t=0
Jul 25 09:14:12 host kernel: vnode: 
Jul 25 09:14:12 host kernel: vnode: 
Jul 25 09:14:12 host kernel: 0xffffff0007e28000: 
Jul 25 09:14:12 host kernel: 0xffffff0007e28000: tag ufs, type VDIRtag ufs, type VDIR
Jul 25 09:14:12 host kernel: usecount 2, writecount 0, refcount 4 mountedhere 0
Jul 25 09:14:12 host kernel: usecount 2, writecount 0, refcount 4 mountedhere 0
Jul 25 09:14:12 host kernel: flags ()
Jul 25 09:14:12 host kernel: flags ()
Jul 25 09:14:12 host kernel: v_object 0xffffff02d81261c0 ref 0 pages 2
Jul 25 09:14:12 host kernel: v_object 0xffffff02d81261c0 ref 0 pages 2
Jul 25 09:14:12 host kernel: 
Jul 25 09:14:12 host kernel: lock type ufs: SHARED (count 2)lock type ufs: SHARED (count 2)
Jul 25 09:14:12 host kernel: ino 49859876, on dev mirror/gm0s1d
Jul 25 09:14:12 host kernel: ino 49859876, on dev mirror/gm0s1d

Those message never had seen before but started appearing at the /var/log/messages after update 8.2 => 8.3

There were both the kernel as well as 'world' updates made from RELENG_8 sources.

The box initially HDD-setup runs under mirror RAID-1 and current output is:
Code: 
# gmirror status
      Name    Status  Components
mirror/gm0  COMPLETE  ad4 (ACTIVE)
                      ad6 (ACTIVE)

As we can see the 'gmirror status' shown Status as COMPLETE.

At the same time, there are 2 lines exist on every system restart:
Code: 
GEOM_MIRROR: Device mirror/gm0 launched (2/2).
GEOM_PART: integrity check failed (mirror/gm0, MBR)

And here is the extra output:
Code: 
# gpart show
=>        63  2930277104  mirror/gm0  MBR  (1.4T) [CORRUPT]
          63  2930277105           1  freebsd  [active]  (1.4T)

=>         0  2930277105  mirror/gm0s1  BSD  (1.4T)
           0    16777216             1  freebsd-ufs  (8.0G)
    16777216     8388608             2  freebsd-swap  (4.0G)
    25165824  2905111281             4  freebsd-ufs  (1.4T)

But 'gpart show' output as:
Code: 
mirror/gm0  MBR  (1.4T) [CORRUPT]

Does anybody has thoughts about all that?
Should I expect further problems derivative by this issue?

Thanks to all for time & efforts reading all that.

Please, note, that this is production box.

Code: 
# uname -a
FreeBSD xyz.host 8.3-STABLE FreeBSD 8.3-STABLE #0 r130: Mon Apr 23 17:41:20 IRKST 2012
 
The first message is due to multiple processors or cores writing output at the same time. It's harmless, can be worked around with PRINTF_BUFR_SIZE=128 in the kernel config. See the GENERIC kernel, also Simplifying FreeBSD Kernel Config Files.

The other kernel messages look to be filesystem errors. A full backup and then a pass with fsck(8) in single user mode won't hurt.

The "corrupt" mirror is due to the gmirror(8) metadata being inside an allocated area of the drive. The updated GEOM is more strict about checking that. See http://www.freebsd.org/releases/9.0R/relnotes-detailed.html#AEN1277.

The reason it is that way is due to following the existing Handbook method for creating the mirror, which is quick and easy but takes a shortcut. The way to fix that is to recreate the mirror so the mirror metadata is not inside the partitions: back up everything, create a mirror of the two drives, create the MBR on that mirror, restore.

I have an updated section of the Handbook which I hope to commit as soon as the doc slush for 9.1-RELEASE ends. PM me if you want to see the draft version.
 
Thank you so much for your explanations in details!

The "corrupt" mirror is due to the gmirror(8) metadata being inside an allocated area of the drive. The updated GEOM is more strict about checking that.
Click to expand...
As I see that this "corrupt" mirror happening to appear after update to 8.3 because of updated version of GEOM only
and this issue was ignored by the earlier 8.2 kernel + 'world'?

In the other words:
- Is there nothing could happened in respect to the data consistency of that initial mirror setup status?
- Is this mirror still running healthy and should work on without further issues with no bothering about process of recreating it? -- The main reason is why I'm asking that because I'm not planning further updates for this box to version 9.x, i.e. it will stay on 8.3 till all the data will be moved to another hardware.

Cheers!
 
As far as I know, the mirror itself is no less safe than it was before. In the very unlikely situation of the filesystem overwriting that last sector, you would lose the mirror metadata. But that's not new, it's the same as it was.

Things like this bother me, so I would fix it. The side benefit is a fresh backup. Of course, a production machine should have those anyway.
 
Very clear picture drawn on topic questions raised.
Let me appreciate you for the helpful info provided!
I will mark this topic as 'Solved'
 
You must log in or register to reply here.
Back
Top