kernel oops mounting xfs

[ese002]

Just in the last week, mounting an xfs volume has beem failing with a kernel "oops"

Code: Select all

Feb  2 19:40:08 crab kernel: XFS (md27): Starting recovery (logdev: internal)
Feb  2 19:40:08 crab kernel: BUG: unable to handle kernel paging request at ffffc90003442000
Feb  2 19:40:08 crab kernel: IP: [<ffffffff813e1d56>] memcpy_erms+0x6/0x10
Feb  2 19:40:09 crab kernel: PGD 40d435067 PUD 40d436067 PMD cbafb067 PTE 0
Feb  2 19:40:09 crab kernel: Oops: 0002 [#1] SMP 
Feb  2 19:40:09 crab kernel: Modules linked in: i915 snd_hda_codec_hdmi drm_kms_helper snd_hda_codec_realtek snd_hda_codec_generic ath9
k syscopyarea sysfillrect sysimgblt snd_hda_intel fb_sys_fops ath9k_common snd_hda_codec x86_pkg_temp_thermal drm ath9k_hw snd_hwdep sn
d_hda_core snd_pcm snd_timer ath r8168(O) snd mac_hid efivarfs ixgb ixgbe mdio tg3 igb i2c_algo_bit e1000 bnx2 atl1c dm_mirror dm_regio
n_hash dm_log dm_mod xhci_plat_hcd sg sata_sil24 sata_sil pata_sil680 sd_mod sr_mod cdrom ahci libahci pata_hpt37x xhci_pci xhci_hcd
Feb  2 19:40:09 crab kernel: CPU: 2 PID: 5020 Comm: mount Tainted: G           O    4.4.26-gentoo #5
Feb  2 19:40:09 crab kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P2.10 07/12/2013
Feb  2 19:40:09 crab kernel: task: ffff880407c54c80 ti: ffff88040aa48000 task.ti: ffff88040aa48000
Feb  2 19:40:09 crab kernel: RIP: 0010:[<ffffffff813e1d56>]  [<ffffffff813e1d56>] memcpy_erms+0x6/0x10
Feb  2 19:40:09 crab kernel: RSP: 0018:ffff88040aa4b8f0  EFLAGS: 00010282
Feb  2 19:40:09 crab kernel: RAX: ffffc90003440a64 RBX: ffff8800cb92f6c0 RCX: 0000000000000a74
Feb  2 19:40:09 crab kernel: RDX: 0000000000002010 RSI: ffff8804088fd59c RDI: ffffc90003442000
Feb  2 19:40:09 crab kernel: RBP: ffff88040aa4b970 R08: 0000000000000060 R09: 0000000000000000
Feb  2 19:40:09 crab kernel: R10: ffffc90003440a00 R11: 0000000000000001 R12: ffff8800cb130800
Feb  2 19:40:09 crab kernel: R13: ffff8800cb92ff80 R14: ffff8800cb3d4800 R15: 0000000000000000
Feb  2 19:40:09 crab kernel: FS:  00007facf6769780(0000) GS:ffff88041f300000(0000) knlGS:0000000000000000
Feb  2 19:40:09 crab kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb  2 19:40:09 crab kernel: CR2: ffffc90003442000 CR3: 000000040a6a8000 CR4: 00000000001406e0
Feb  2 19:40:09 crab kernel: Stack:
Feb  2 19:40:09 crab kernel:  ffffffff8135cdb7 ffff880409cc9b40 ffff88040aa4b968 0000000000000001
Feb  2 19:40:09 crab kernel:  0000006081854dc0 ffffc90003440a00 ffff88040aa4ba10 ffff88040849d080
Feb  2 19:40:09 crab kernel:  0000000000000000 000000000f06ea00 ffff880000000010 ffff8800cb92ff80
Feb  2 19:40:09 crab kernel: Call Trace:
Feb  2 19:40:09 crab kernel:  [<ffffffff8135cdb7>] ? xlog_recover_inode_pass2+0x5a7/0x980
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d249>] xlog_recover_commit_pass2+0xb9/0x190
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d35c>] xlog_recover_items_pass2+0x3c/0x60
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d586>] xlog_recover_commit_trans+0x206/0x270
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d66a>] xlog_recovery_process_trans+0x7a/0xb0
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d703>] xlog_recover_process_ophdr+0x63/0xc0
Feb  2 19:40:09 crab kernel:  [<ffffffff8135d7fd>] xlog_recover_process_data+0x9d/0xc0
Feb  2 19:40:09 crab kernel:  [<ffffffff8135dc5d>] xlog_do_recovery_pass+0x43d/0x540
Feb  2 19:40:09 crab kernel:  [<ffffffff8135ddd9>] xlog_do_log_recovery+0x79/0xc0
Feb  2 19:40:09 crab kernel:  [<ffffffff8135de31>] xlog_do_recover+0x11/0xe0
Feb  2 19:40:09 crab kernel:  [<ffffffff8135e8d3>] xlog_recover+0xa3/0x140
Feb  2 19:40:09 crab kernel:  [<ffffffff81352d28>] xfs_log_mount+0xd8/0x2b0
Feb  2 19:40:09 crab kernel:  [<ffffffff8134ac24>] xfs_mountfs+0x4d4/0x810
Feb  2 19:40:09 crab kernel:  [<ffffffff8134b9b6>] ? xfs_mru_cache_create+0x126/0x180
Feb  2 19:40:09 crab kernel:  [<ffffffff8134d896>] xfs_fs_fill_super+0x386/0x490
Feb  2 19:40:09 crab kernel:  [<ffffffff811a92fb>] mount_bdev+0x17b/0x1b0
Feb  2 19:40:09 crab kernel:  [<ffffffff8134d510>] ? xfs_parseargs+0xa90/0xa90
Feb  2 19:40:09 crab kernel:  [<ffffffff8134bf70>] xfs_fs_mount+0x10/0x20
Feb  2 19:40:09 crab kernel:  [<ffffffff811a9e03>] mount_fs+0x33/0x160
Feb  2 19:40:09 crab kernel:  [<ffffffff811769d0>] ? __alloc_percpu+0x10/0x20
Feb  2 19:40:09 crab kernel:  [<ffffffff811c3b72>] vfs_kern_mount+0x62/0x100
Feb  2 19:40:09 crab kernel:  [<ffffffff811c6027>] do_mount+0x217/0xd00
Feb  2 19:40:09 crab kernel:  [<ffffffff811a17a6>] ? __kmalloc_track_caller+0xc6/0x180
Feb  2 19:40:09 crab kernel:  [<ffffffff811725ac>] ? strndup_user+0x3c/0x90
Feb  2 19:40:09 crab kernel:  [<ffffffff8117253d>] ? memdup_user+0x3d/0x70
Feb  2 19:40:09 crab kernel:  [<ffffffff811c6e06>] SyS_mount+0x86/0xc0
Feb  2 19:40:09 crab kernel:  [<ffffffff817b919b>] entry_SYSCALL_64_fastpath+0x16/0x6e
Feb  2 19:40:09 crab kernel: Code: 90 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 
Feb  2 19:40:09 crab kernel: RIP  [<ffffffff813e1d56>] memcpy_erms+0x6/0x10
Feb  2 19:40:09 crab kernel:  RSP <ffff88040aa4b8f0>
Feb  2 19:40:09 crab kernel: CR2: ffffc90003442000
Feb  2 19:40:09 crab kernel: ---[ end trace 5e5a396d6e977abe ]---

Not only does the volume fail to mount, it creates problems for other volumes. Notably, dump hangs on all volumes (different disks. different file systems) and cannot be killed.

If I disable boot time mounting and try to repair, this is what I get.

Code: Select all

crab /home/eric # xfs_repair /dev/md27
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

If I mount manually, mount returns "killed". If I try a second time, it hangs.

No files have been added, deleted, or modified in a month so can I assume the metadata is just atime and safe to delete? That is if the corruption is even real. Other volumes share the same physical disks and are fine. I have one other xfs volume on different media and it is fine. How do I even determine what (if any) corruption exists? I don't seem to have xfs_check.

[TigerJr]

Dirty writes on higher levels cache can corrupt log and crc of superblock after power loose, maybe?

Error gives you a mounting advice with destroying log, are you tryed or afraid of loosing data, do you have backups?

can you look at xfs_info of /dev/md27 ?

[ese002]

Code: Select all

xfs_info /dev/md27
meta-data=/dev/md27              isize=256    agcount=32, agsize=5242871 blks
         =                       sectsz=4096  attr=2, projid32bit=0
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=167771870, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=0
log      =internal log           bsize=4096   blocks=81919, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

I do have backups but there is always the concern whether the rsync backups are 100% faithful. No power loss that I can recall.

[TigerJr]

Code: Select all

xfs_info /dev/md27
meta-data=/dev/md27              isize=256    agcount=32, agsize=5242871 blks
         =                       sectsz=4096  attr=2, projid32bit=0
         =                       crc=0        finobt=0, sparse=0, rmapbt=0
         =                       reflink=0
data     =                       bsize=4096   blocks=167771870, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=0
log      =internal log           bsize=4096   blocks=81919, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

I do have backups but there is always the concern whether the rsync backups are 100% faithful. No power loss that I can recall.

-m crc=1 -n ftype=1 now is default parameters for xfsprog, i think that is old xfs format, are you update xfsprogs?

Code: Select all

livecd / # xfs_info /dev/sda1
meta-data=/dev/sda1              isize=256    agcount=4, agsize=1904960 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=7619840, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=3720, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

If you have well backups and

If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.

Are you tryed?

[Hu]

Code: Select all

Feb  2 19:40:09 crab kernel: CPU: 2 PID: 5020 Comm: mount Tainted: G           O    4.4.26-gentoo #5

This is a very old kernel, and not even close to current even on the 4.4.x line. Please try an updated kernel to see if it can handle the error more gracefully.

[ese002]

Code: Select all

Feb  2 19:40:09 crab kernel: CPU: 2 PID: 5020 Comm: mount Tainted: G           O    4.4.26-gentoo #5

This is a very old kernel, and not even close to current even on the 4.4.x line. Please try an updated kernel to see if it can handle the error more gracefully.

I did. I built 4.19.97. No difference.

[TigerJr]

Xfs format doesn't changes then you only update kernel. Format changed than you use updated xfsprogs and reformating your partition device... i think. If you update kernel and mount filesystem, than new xfs driver need to work with old xfs format parameters. As i think.

Tell me if i think wrong.

[Hu]

TigerJr, what are you trying to say here? The point of the upgrade request was a hope that a newer kernel would have better handling for whatever condition is causing the problem.

ese002: please try with 5.5.x. If it still fails, post the output of that failure.

[TigerJr]

If you formated your partition in a very old age, that format would be used across all kernels.

Maybe that mount corrupts log after kernel updated or xfsprogs update

[Hu]

Most people recreate their filesystems as seldom as possible. The kernel usually tries to support all released versions of a filesystem, even very archaic ones, because users would object to recreating the filesystem as a precondition to upgrading the kernel. In the case of the ext family, there were even special steps available to enable some ext4 features on filesystems that were originally made as ext3, so that users could get some of the new functionality without recreating the filesystem. I'm not familiar with the XFS developers, but I'd be surprised if they were cavalier about breaking support for old versions.

[TigerJr]

Long time ago i think the same, old format should supported in all kernels.

But im encountered with similar probem with XFS grub-0.97-r13 doesn't install on xfs partition, it doesn't recognized XFS partition anymore and long time i search the reason for that.

[ese002]

TigerJr, what are you trying to say here? The point of the upgrade request was a hope that a newer kernel would have better handling for whatever condition is causing the problem.

ese002: please try with 5.5.x. If it still fails, post the output of that failure.

The latest sys-fs/xfsprogs in portage is 5.4.0, which is what I am running.

[Hu]

The latest kernel is 5.5.x though, and since the kernel is what is printing errors, a newer kernel is the most interesting part to upgrade.

[ese002]

The latest kernel is 5.5.x though, and since the kernel is what is printing errors, a newer kernel is the most interesting part to upgrade.

The latest in stable is 4.19.97

[ese002]

With 5.5.2-r1, the results from a mount attempt are pretty similar.

Code: Select all

Feb 11 22:27:48 crab kernel: XFS (md27): Mounting V4 Filesystem
Feb 11 22:27:48 crab kernel: XFS (md27): Starting recovery (logdev: internal)
Feb 11 22:27:48 crab kernel: BUG: unable to handle page fault for address: ffffc90008802000
Feb 11 22:27:48 crab kernel: #PF: supervisor write access in kernel mode
Feb 11 22:27:48 crab kernel: #PF: error_code(0x0002) - not-present page
Feb 11 22:27:48 crab kernel: PGD 40d892067 P4D 40d892067 PUD 40d893067 PMD 408193067 PTE 0
Feb 11 22:27:49 crab kernel: Oops: 0002 [#1] SMP PTI
Feb 11 22:27:49 crab kernel: CPU: 3 PID: 9216 Comm: mount Not tainted 5.5.2-gentoo-r1 #1
Feb 11 22:27:49 crab kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Pro3, BIOS P2.10 07/12/2013
Feb 11 22:27:49 crab kernel: RIP: 0010:memcpy_erms+0x6/0x10
Feb 11 22:27:49 crab kernel: Code: 52 5b c3 c3 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 
<f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
Feb 11 22:27:49 crab kernel: RSP: 0018:ffffc90002f17a18 EFLAGS: 00010282
Feb 11 22:27:49 crab kernel: RAX: ffffc90008800a64 RBX: ffff8882bbc68000 RCX: 0000000000000a74
Feb 11 22:27:49 crab kernel: RDX: 0000000000002010 RSI: ffff888340d0559c RDI: ffffc90008802000
Feb 11 22:27:49 crab kernel: RBP: ffffc90002f17a88 R08: 0000000000000000 R09: 0000000000002010
Feb 11 22:27:49 crab kernel: R10: ffffc90008800a00 R11: ffff8882bbf78a80 R12: ffff8883fb15aac0
Feb 11 22:27:49 crab kernel: R13: ffff888281437980 R14: 0000000000000000 R15: ffff888409b23000
Feb 11 22:27:49 crab kernel: FS:  00007f459188c780(0000) GS:ffff88840f780000(0000) knlGS:0000000000000000
Feb 11 22:27:49 crab kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 11 22:27:49 crab kernel: CR2: ffffc90008802000 CR3: 000000023bd84004 CR4: 00000000001606e0
Feb 11 22:27:49 crab kernel: Call Trace:
Feb 11 22:27:49 crab kernel:  xlog_recover_inode_pass2+0x5b6/0x970
Feb 11 22:27:49 crab kernel:  xlog_recover_items_pass2+0x37/0x50
Feb 11 22:27:49 crab kernel:  xlog_recover_commit_trans+0x253/0x270
Feb 11 22:27:49 crab kernel:  xlog_recovery_process_trans+0xc3/0xe0
Feb 11 22:27:49 crab kernel:  xlog_recover_process_data+0xa5/0x130
Feb 11 22:27:49 crab kernel:  xlog_do_recovery_pass+0x508/0x600
Feb 11 22:27:49 crab kernel:  ? irq_work_queue+0x13/0x20
Feb 11 22:27:49 crab kernel:  ? wake_up_klogd+0x2b/0x30
Feb 11 22:27:49 crab kernel:  xlog_do_log_recovery+0x7a/0xa0
Feb 11 22:27:49 crab kernel:  xlog_do_recover+0x30/0x190
Feb 11 22:27:49 crab kernel:  xlog_recover+0xd2/0x160
Feb 11 22:27:49 crab kernel:  xfs_log_mount+0x151/0x2b0
Feb 11 22:27:49 crab kernel:  xfs_mountfs+0x440/0x870
Feb 11 22:27:49 crab kernel:  xfs_fc_fill_super+0x2c7/0x4a0
Feb 11 22:27:49 crab kernel:  ? xfs_mount_free+0x30/0x30
Feb 11 22:27:49 crab kernel:  get_tree_bdev+0x155/0x230
Feb 11 22:27:49 crab kernel:  vfs_get_tree+0x20/0xb0
Feb 11 22:27:49 crab kernel:  do_mount+0x73d/0x950
Feb 11 22:27:49 crab kernel:  ? memdup_user+0x3c/0x80
Feb 11 22:27:49 crab kernel:  __x64_sys_mount+0x89/0xc0
Feb 11 22:27:49 crab kernel:  do_syscall_64+0x47/0x190
Feb 11 22:27:49 crab kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Feb 11 22:27:49 crab kernel: RIP: 0033:0x7f4591a1f8ea
Feb 11 22:27:49 crab kernel: Code: 48 8b 0d a9 25 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 25 0c 00 f7 d8 64 89 01 48
Feb 11 22:27:49 crab kernel: RSP: 002b:00007ffcd79374e8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
Feb 11 22:27:49 crab kernel: RAX: ffffffffffffffda RBX: 00007f4591b45f44 RCX: 00007f4591a1f8ea
Feb 11 22:27:49 crab kernel: RDX: 000055a8bdbc7650 RSI: 000055a8bdbc7ac0 RDI: 000055a8bdbc7aa0
Feb 11 22:27:49 crab kernel: RBP: 000055a8bdbc7440 R08: 0000000000000000 R09: 000055a8bdbc7b0d
Feb 11 22:27:49 crab kernel: R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
Feb 11 22:27:49 crab kernel: R13: 000055a8bdbc7aa0 R14: 0000000000000000 R15: 000055a8bdbc7650
Feb 11 22:27:49 crab kernel: Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 ath9k iosf_mbi ath9k_common drm_kms_helper snd_hda_intel snd_intel_dspcfg x86_pkg_temp_thermal ath9k_hw snd_hda_codec syscopyarea sysfillrect sysimgblt snd_hwdep fb_sys_fops snd_hda_core drm snd_pcm snd_timer ath snd mac_hid efivarfs ecb ixgb ixgbe mdio tg3 igb i2c_algo_bit e1000 bnx2 atl1c dm_mirror dm_region_hash dm_log dm_mod xhci_plat_hcd sg sata_sil24 sata_sil pata_sil680 sr_mod sd_mod cdrom ahci libahci pata_hpt37x xhci_pci xhci_hcd
Feb 11 22:27:49 crab kernel: CR2: ffffc90008802000
Feb 11 22:27:49 crab kernel: ---[ end trace 6b35f121cd7a1b08 ]---
Feb 11 22:27:49 crab kernel: RIP: 0010:memcpy_erms+0x6/0x10
Feb 11 22:27:49 crab kernel: Code: 52 5b c3 c3 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe
Feb 11 22:27:49 crab kernel: RSP: 0018:ffffc90002f17a18 EFLAGS: 00010282
Feb 11 22:27:49 crab kernel: RAX: ffffc90008800a64 RBX: ffff8882bbc68000 RCX: 0000000000000a74
Feb 11 22:27:49 crab kernel: RDX: 0000000000002010 RSI: ffff888340d0559c RDI: ffffc90008802000
Feb 11 22:27:49 crab kernel: RBP: ffffc90002f17a88 R08: 0000000000000000 R09: 0000000000002010
Feb 11 22:27:49 crab kernel: R10: ffffc90008800a00 R11: ffff8882bbf78a80 R12: ffff8883fb15aac0
Feb 11 22:27:49 crab kernel: R13: ffff888281437980 R14: 0000000000000000 R15: ffff888409b23000
Feb 11 22:27:49 crab kernel: FS:  00007f459188c780(0000) GS:ffff88840f780000(0000) knlGS:0000000000000000
Feb 11 22:27:49 crab kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 11 22:27:49 crab kernel: CR2: ffffc90008802000 CR3: 000000023bd84004 CR4: 00000000001606e0

[Hu]

Good. If it's broken in v5.5.x, it's probably still broken in the v5.6-rc series, and hopefully upstream will not ask you to test that before accepting that the problem merits attention. I think you are ready to take this to the kernel developers. Show them the backtrace you posted here from the v5.5.x kernel. Tell them anything you know about how the filesystem got into this state. Think about whether the filesystem has anything private on it. If it does not and you are willing to share a dump of it, that may be easier for them to debug, but wait for them to request it before you send the dump. (You could open with an offer to provide the dump, though.) Beware that it could be difficult to withhold private data from the dump, so if the filesystem has anything you would rather not share, you should not provide a dump without expert guidance on how to filter it.

[ese002]

Ok. Where does one report bugs to XFS upstream? I see a lot of broken links and stale pages.

[Muso]

Just my $0.02, but XFS was one of the filesystems which caused me data loss from a power outage. The other was JFS.

[Hu]

Ok. Where does one report bugs to XFS upstream?

I don't know, but if I had to guess, I would start by inspecting the MAINTAINERS file in the kernel source, and look at who is responsible for the directory fs/xfs/. For me, that block reads:

Code: Select all

XFS FILESYSTEM
M:	Darrick J. Wong <darrick.wong@oracle.com>
M:	linux-xfs@vger.kernel.org
L:	linux-xfs@vger.kernel.org
W:	http://xfs.org/
T:	git git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
S:	Supported
F:	Documentation/admin-guide/xfs.rst
F:	Documentation/ABI/testing/sysfs-fs-xfs
F:	Documentation/filesystems/xfs-delayed-logging-design.txt
F:	Documentation/filesystems/xfs-self-describing-metadata.txt
F:	fs/xfs/
F:	include/uapi/linux/dqblk_xfs.h
F:	include/uapi/linux/fsmap.h

Therefore, I would start with contacting the shown mailing list. I'm unsure on etiquette regarding contacting specifically listed people for a report like this, so I would start with just the list. (If you really want to start by contacting the named individual, I would still CC the list, so that other interested developers are aware of the report.)

There's a script that can decipher this data, but for what you need, it's probably sufficient to read the block by hand.