# kernel oops mounting xfs

## ese002

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

```
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.

```
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

```
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

 *ese002 wrote:*   

> 
> 
> ```
> xfs_info /dev/md27
> 
> ...

 

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

```

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

 *Quote:*   

> 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

 *ese002 wrote:*   

> 
> 
> ```
> 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

 *Hu wrote:*   

>  *ese002 wrote:*   
> 
> ```
> Feb  2 19:40:09 crab kernel: CPU: 2 PID: 5020 Comm: mount Tainted: G           O    4.4.26-gentoo #5
> ```
> ...

 

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

 *Hu wrote:*   

> 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

 *Hu wrote:*   

> 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.

```

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

 *ese002 wrote:*   

> 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:

```
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.

----------

